Age | Commit message (Collapse) | Author |
|
We can not pass None as VRF name, this raises an exception.
OSError: [Errno 255] failed to run command: ip link set dev eth2 master None
|
|
|
|
|
|
|
|
Do not create rfc3768-compatibility interfaces by default because of wrong
Jinja2 syntax. Backporting the entire system makes it easier in the future to
additional bugfixes.
|
|
(cherry picked from commit 2974628487abb9127922bf695331fd706a1d0e51)
|
|
Instead of throwing an exception when an adapters autoneg capabilities can not
be detected, just pretend it does not support autoneg.
(cherry picked from commit 0b414bcd2930a1469df0a747962f4650d0fb964b)
|
|
dhclient: T3852: Fixed dhclient processes search
|
|
Backported commits:
13abffe43b2a5c41bb4ec4675c227f6cf1f868da
01158a8eaa574c48c726c20693479e4aa6e18ee6
This allows finding all running dhclient processes properly.
|
|
openvpn: T690: Fix template for gateway and metric
|
|
Some OpenVPN clients doesnt support option gateway and metric.
Set metric option only when 'metric' was added in config
explicity.
|
|
The group CLI node takes a multicast IPv4 or IPv6 address - this must be input
validated to not case any OS exception
cpo@LR1.wue3# show interfaces vxlan
vxlan vxlan0 {
+ group 254.0.0.1
source-address 172.18.254.201
+ source-interface dum0
vni 10
}
Results in OSError beeing rasied with the following context:
Error: argument "254.0.0.1" is wrong: invalid group address
(cherry picked from commit 0d7cd4ed5725d3e79faad5abc0801631c2ffc813)
|
|
|
|
Commit 081e23996f (vyos.ifconfig: get_mac_synthetic() must generate a stable
"MAC") calculated a "stable" synthetic MAC address per the interface based on
UUID and the interface name. The problem is that this calculation is too stable
when run on multiple instances of VyOS on different hosts/hypervisors.
Having R1 and R2 setup a connection both via "tun10" interface will become the
same "synthetic" MAC address manifesting in the same link-local IPv6 address.
This e.g. breaks OSPFv3 badly as both neighbors communicate using the same
link-local address.
As workaround one can:
set interfaces tunnel tun1337 address 'fe80::1:1337/64'
set interfaces tunnel tun1337 ipv6 address no-default-link-local
This commit changes the way in how the synthetic MAC address is generated. It's
based on the first 48 bits of a sha256 sum build from a CPU ID retrieved via
DMI, the MAC address of eth0 and the interface name as used before. This should
add enough entropy to get a stable pseudo MAC address.
(cherry picked from commit 8d6861290f39298701b0a89bd358545763cee14b)
|
|
(cherry picked from commit 0ee26592772a14e829d9d1f8e64f9db875f31a63)
|
|
The <command> node was missed out when adding the XML definitions.
(cherry picked from commit 801123eff1bf232ca1e5202ceb0989c2fba34c86)
|
|
(cherry picked from commit d1c58addd881e06b389799a9c14d8ebf5d03c567)
|
|
Commit dd2eb5e5686655 ("dhcp: T3300: add DHCP default route distance") changed
the logic on how the DHCP process is going to be started. The systemd unit was
always "started" even if it was already running. It should rather be re-started
to track changes in e.g. the DHCP hostname setting.
(cherry picked from commit 8ba8f0e097527e3aaaf8b395bfc07cce47e2c788)
|
|
(cherry picked from commit 6187ce264a39cd72285f6cb73cc746a04268c253)
|
|
This reverts commit 38e02c12a50de685c6d70954cd94a224e8083f0b.
|
|
(cherry picked from commit 6935c263f5022896e96bec9daa8a5ba29b04b51b)
|
|
Commit 260f3832 ("vrrp: keepalived: T616: drop /etc/default/keepalived") dropped
the old daemon configuration but there was one line of code that tried to delete
the file which was no longer present.
This resulted in: KeyError: 'daemon'
|
|
This is a follow-up commit to 65398e5c8 ("vrrp: keepalived: T616: move
configuration to volatile /run directory") as it makes no sense to store a
static /etc/default/keepalived file marked as "Autogenerated by VyOS" that only
enabled the SNMP option to keepalived.
Better pass the --snmp switch via the systemd override file and drop all other
references/files.
|
|
(cherry picked from commit 590cf0e626f6a5e813ec4f3021c028a5e098e27d)
|
|
Move keepalived configuration from /etc/keepalived to /run/keepalived.
(cherry picked from commit b243795eba1b36cadd81c3149e833bdf5c5bea70)
|
|
(cherry picked from commit ddda0d66faa73900ed2b8fec1dde38ffc4a49fcd)
|
|
(cherry picked from commit 6541bdbe792a3cc420f0367e673f27763528376c)
|
|
This is a successor to commit a2ac9fac16e ("vyos.template: T2720: always enable
Jinja2 trim_blocks feature"). It only shifts the whitespaces / indents inside
the keepalived configuration file.
(cherry picked from commit c1ac0630cfe0ee65569fbe435cc006ade20fed22)
|
|
shared-network
(cherry picked from commit 689d1824d251ea9fbd81bf0c941dbd36e33ef420)
|
|
(cherry picked from commit 61aed576582cedc38cafa758651f1446d4ba4d34)
|
|
(cherry picked from commit 3f6ae12908f54222f2f79a87bed51f71e2fbac87)
|
|
Commit b7d30137b1 ("vyos.ifconfig: provide generic get_mac_synthetic() method")
provided a common helper to generate MAC addresses used by EUI64 addresses for
interfaces not having a layer2 interface (WireGuard or ip tunnel).
The problem is that every call to the helper always yielded a new MAC address.
This becomes problematic when IPv6 link-local addresses are generated and
modified on the interface as multiple link-local (fe80::/64) addresses can
easily be added to the interface leaving ... a mess.
This commit changes the way how the "synthetic" MAC is generated, we generate a
UUID which is stable as it is based on the interface name. We take out the last
48 bits of the UUID and form the "MAC" address.
(cherry picked from commit 081e23996feb60ad903caf8b0a4587f5dacc69bf)
|
|
Required by the vyos.ifconfig library - backported from 1.4 (current)
|
|
When IPv6 is disbaled on an interface also the sysfs files related to IPv6 for
this interface vanish. We need to check if the file exists before we read it.
(cherry picked from commit 672a70613aa6c987bca417f93b587eddccbfd53a)
|
|
When using VRRP on any given interface and performing an action against that
interface - be it even only changing the alias - will trigger a removal of the
VRRP IP address.
The issue is caused by:
# determine IP addresses which are assigned to the interface and build a
# list of addresses which are no longer in the dict so they can be removed
cur_addr = self.get_addr()
for addr in list_diff(cur_addr, new_addr):
When the script calls into the library - we will drop all IP addresses set on
the adapter but not available in the config dict.
We should only remove the IP addresses marked by the CLI to be deleted!
(cherry picked from commit e80d0aebd691f1a707ab534b4d1340fa0b793e01)
|
|
node is added
Commit f476e456 ("vyos.configdict: leaf_node_changed() must return empty dict
when node is added") returned [''] as "empty" dict - but this is not empty.
>>> if ['']:
... print('foo')
...
foo
It should rather be: []
(cherry picked from commit e28a80a2b742ea3d9d4bcb8ae66c7a0d51aaaff6)
|
|
There is no need to alter interface parameters if they have not changed at all.
(cherry picked from commit b4c58c5aefaca4fce817b58327b9c7c3e8145d6d)
|
|
Commit 2985035b (dhcp-server: T3672: re-add missing "name" CLI option)
unfortunately did not add the name option to the migration script.
(cherry picked from commit e83a113360ba18043edcf7f70689c7042dee2b37)
|
|
(cherry picked from commit 59e5b5eb4c0507f9d3831483152a748b58560bfd)
|
|
(cherry picked from commit 2f8b33a26e63e5b9ac4e697b9312f2238d6241f3)
|
|
DHCP servers "shared-network" level only makes sense if one can specify
configuration items that can be inherited by individual subnets. This is now
possible for name-servers and the domain-name.
set service dhcp-server shared-network-name LAN domain-name 'vyos.net'
set service dhcp-server shared-network-name LAN name-server '192.0.2.1'
(cherry picked from commit d411a40a3598c55fae7abd8bc5f1876007aa704b)
|
|
(cherry picked from commit 90dffcb3c14ec976fecae32d19a979f05a40d9c8)
|
|
(cherry picked from commit 564f05614b6e8650185c46b9625f6a0cd9661639)
|
|
(cherry picked from commit 88f71fc6b5b3bd89623c3d5f0af1c7dbd19f0996)
|
|
(cherry picked from commit a85ff749bb84d562b711171768cdc92498ad7406)
|
|
The DHCP servers pool {} option can only be used when there follows a range
statement. This is invalid for a network with only "static" leases.
(cherry picked from commit 6c2c089c26f1652644c9ded7d5cfd8a0497f148e)
|
|
(cherry picked from commit 83ea0cb273e29db22062cc133b6eabd4ba2761c7)
|
|
This option is mandatory and must be user configurable as it needs to match
on both sides.
(cherry picked from commit 2985035bcb2f3732e15a41e3c2ee6c6c93a6836e)
|
|
(cherry picked from commit a8ccf72c222caad8cd7aaca9bca773be39e87f5c)
|
|
IPv4 DHCP uses "dns-server" to specify one or more name-servers for a given
pool. In order to use the same CLI syntax this should be renamed to name-server,
which is already the case for DHCPv6.
(cherry picked from commit e2f9f4f4e8b2e961a58d935d09798ddb4e1e0460)
|