Age | Commit message (Collapse) | Author |
|
The VLAN aware bridge was forwarding traffic between member ports, but traffic
destined torwards the CPU was dropped. This resulted in a gateway not reachable
or DHCP leases that could not be handed out.
Tested via:
VyOS
set interfaces bridge br0 enable-vlan
set interfaces bridge br0 member interface eth1 allowed-vlan '10'
set interfaces bridge br0 member interface eth1 allowed-vlan '20'
set interfaces bridge br0 member interface eth1 allowed-vlan '30'
set interfaces bridge br0 member interface eth1 allowed-vlan '40'
set interfaces bridge br0 member interface eth1 native-vlan '40'
set interfaces bridge br0 member interface eth2 allowed-vlan '30'
set interfaces bridge br0 member interface eth2 allowed-vlan '20'
set interfaces bridge br0 member interface eth2 allowed-vlan '10'
set interfaces bridge br0 member interface eth2 allowed-vlan '40'
set interfaces bridge br0 vif 10 address '10.0.10.1/24'
set interfaces bridge br0 vif 20 address '10.0.20.1/24'
set interfaces bridge br0 vif 30 address '10.0.30.1/24'
set interfaces bridge br0 vif 40 address '10.0.40.1/24'
Arista vEOS
vlan 10,20,30,40
interface Ethernet1
switchport trunk allowed vlan 10,20,30,40
interface Vlan10
ip address 10.0.10.2/24
interface Vlan20
ip address 10.0.20.2/24
interface Vlan30
ip address 10.0.30.2/24
interface Vlan40
ip address 10.0.40.2/24
interface Ethernet1
switchport trunk allowed vlan 10,20,30,40
switchport mode trunk
spanning-tree portfast
Cisco vIOS
interface GigabitEthernet0/0
ip address 10.0.40.3 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/0.10
encapsulation dot1Q 10
ip address 10.0.10.3 255.255.255.0
!
interface GigabitEthernet0/0.20
encapsulation dot1Q 20
ip address 10.0.20.3 255.255.255.0
!
interface GigabitEthernet0/0.30
encapsulation dot1Q 30
ip address 10.0.30.3 255.255.255.0
!
(cherry picked from commit f60d0e1ce029925b843f635b36154c90049b9577)
|
|
mtu: T4572: Add DHCP-option MTU to get values from DHCP-server
|
|
Ability to get MTU from DHCP-server and don't touch it per
any interface change if interface 'dhcp-options mtu' is
configured
(cherry picked from commit 29b0ee30bf2622a40ca3d17e3f6b9e94e5b62072)
|
|
(cherry picked from commit 54227591a0eb3c7aa8c896c6ec8b1826ce070ddf)
|
|
Interface() base class already takes care about VLAN creation/removal of
newly added or no longer required interfaces. No need to code this logic again.
(cherry picked from commit 41477cc85208507be55f8db4e412ad78eae764eb)
|
|
When removing a VRF from an ethernet interface and adding the interface to a
bond in the same commit led to an OSError: [Errno 16] Device or resource busy!
(cherry picked from commit 3592f56a8deb6c44dcdd7a44ef54fc2c39eb1a3b)
|
|
Linux Kernel supports to specify the MII link monitoring frequency in
milliseconds. This determines how often the link state of each slave is
inspected for link failures. A value of zero disables MII link monitoring.
A value of 100 is a good starting point.
The default value is 100.
set interfaces bonding bond0 mii-mon-interval <n>
(cherry picked from commit 4315c8fa5bb090e2b7edd6bda205041623e2511d)
|
|
(cherry picked from commit cabfd006bed9cd2d1512cb313616a8e97fe29b9e)
|
|
The code path for changing the interval is never executed.
(cherry picked from commit daddb0ad7812843f64a7ae0bf4b5e15db7b1758e)
|
|
T4331: IPv6 link local addresses are not configured when an interface is in a VRF (equuleus)
|
|
If we have link-local static address and vrf, for example:
set interfaces ethernet eth2 address 'fe80::5200:ff:fe55:222/64'
set interfaces ethernet eth2 vrf 'foo'
This IPv6 address was assigned before vrf, as result after
attaching the intreface to vrf we lose this static linklocal
address
DEBUG/IFCONFIG cmd 'ip addr add fe80::5200:ff:fe55:222/64 dev eth2'
DEBUG/IFCONFIG cmd 'ip link set dev eth2 master foo'
DEBUG/IFCONFIG cmd 'ip addr add fe80::5208:ff:fe13:2/64 dev eth2'
This commit fixes this, the address is assigned after vrf assign
(cherry picked from commit d6e22b28887c7a3f7d2f8b955c2e90bcadaeeeba)
|
|
This extends the fix from 53e20097 ("vyos.ifconfig: T4330: bugfix changing MTU
when IPv6 is disabled") by ordering the execution in a way the Kernel does not
complain.
(cherry picked from commit 601ab19fd8c81a998b3c966cc83b85ed60ac5ae0)
|
|
Commit f8b3d8999c ("ipv6: T4319: do not configure IPv6 related settings if it's
disabled") moved the MTU configuration part under the code path which is only
run if IPv6 is enabled on the system.
This prevented MTU changes on IPv6 disabled systems.
(cherry picked from commit 53e20097d227ebf4bdb4dc6c85427ec9c5ec3982)
|
|
(cherry picked from commit 60f009defadb9d36bf84def1e839cb11a0b3d619)
|
|
(cherry picked from commit df0fbfeedce0f163e9d10be21d58ad4dc797a28a)
|
|
|
|
(cherry picked from commit f8b3d8999cbea988ce8e7d303957558308ddc1bc)
|
|
(cherry picked from commit 3a605ad020d8d20b08a72cb1284f6e590d1fd7b5)
|
|
VXLAN does support using multiple remotes but VyOS does not. Add the ability
to set multiple remotes and add their flood lists using "bridge" command.
(cherry picked from commit 0ecddff7cffa8900d351d5c15e32420f9d780c0b)
|
|
In the past whenever a change happened to any interface and it was configured
as a DHCP client, VyOS always had a breif outage as DHCP released the old lease
and re-aquired a new one - bad!
This commit changes the behavior that DHCP client is only restarted if any one
of the possible options one can set for DHCP client under the "dhcp-options"
node is altered.
(cherry picked from commit 3a1a7c40a13ee9f5561823a79876d88d3f5bf053)
|
|
VLAN isolation can not be "set" when interface is of type wifi.
(cherry picked from commit 1ceaed55a629c92cf42baccdef4106e8d0e4914e)
|
|
Ability to see interface type "input" ifbX from op-mode
(cherry picked from commit 5fdf4e5988344f7a890fe351183b58b8e21699c2)
|
|
to avoid confusing 'v' in GENEVE interface prefix ('gnv')
with a "vXXX" part of a VRRP interface
|
|
Interface will still be visible to the operating system.
(cherry picked from commit a14f93adfa633eabff90524e1f83d56092ec0c3c)
|
|
Improve commend in WWANIf.remove() - remove() was implemented in commit 61e4d75a
("wwan: T3620: place interface in A/D state when removed").
(cherry picked from commit d9a19b77a56031fa3fbfa43a85c8be7ee83ae3d7)
|
|
|
|
It seems not all systems have eth0 - get a list of all available Ethernet
interfaces on the system (without VLAN subinterfaces) and then take the
first one.
(cherry picked from commit f19c92f255011149eeb7626a2e158456abe4c9b8)
|
|
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
|
|
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 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)
|
|
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.
|
|
Move keepalived configuration from /etc/keepalived to /run/keepalived.
(cherry picked from commit b243795eba1b36cadd81c3149e833bdf5c5bea70)
|
|
(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)
|
|
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)
|
|
There is no need to alter interface parameters if they have not changed at all.
(cherry picked from commit b4c58c5aefaca4fce817b58327b9c7c3e8145d6d)
|
|
states
Turns out an AX88179 USB 3.0 NIC does not support reading back the speed and
duplex settings in every operating state. While the NIC is beeing
initialized, reading the speed setting will return:
$ cat /sys/class/net/eth6/speed
cat: /sys/class/net/eth6/speed: Invalid argument
Thus if this happens, we simply tell the system that the current NIC speed
matches the requested speed and nothing is changed at this point in time.
|
|
Move the two implementations to get the driver name of a NIC from ethernet.py
and ethtool.py to only ethtool.py.
|
|
|
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
(cherry picked from commit 0229645c8248decb5664056df8aa5cd5dff41802)
|
|
Only update the RX/TX ring-buffer settings if they are different from the ones
currently programmed to the hardware. There is no need to write the same value
to the hardware again - this could cause traffic disruption on some NICs.
(cherry picked from commit 29082959e0efc02462fba8560d6726096e8743e9)
|
|
It makes no sense to have a parser for the ethtool value sin ethtool.py
and ethernet.py - one instance ios more then enough!
(cherry picked from commit 6f5fb5c503b5df96d0686002355da3633b1fc597)
|
|
This makes understanding the code easier what is "really" called without
opening the man page.
(cherry picked from commit a086dc2c429aea9614ac7a9c735c6475c2d6da59)
|
|
Some tc qdisc rules are generated by old perl code
It prevent to unexpected override this code by python.
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
|
|
option
Commit 31169fa8 ("vyos.ifconfig: T3619: only set offloading options if
supported by NIC") added a warning for the user if an offload option was about
to change that was not possible at all (harware limit).
Unfortunately the warning was even displayed if nothing was done at all. This
got corrected.
(cherry picked from commit ce784a9fcb7199f87949f17777b7b736227c85b3)
|
|
Check eui64_old value before deleting
It can be empty or not ipv6 address.
|
|
In the past we always told ethtool to change the offloading settings, even if
this was not supported by the underlaying driver.
This commit will only change the offloading options if they differ from the
current state of the NIC and only if it's supported by the NIC. If the NIC does
not support setting the offloading options, a message will be displayed
for the user:
vyos@vyos# set interfaces ethernet eth2 offload gro
vyos@vyos# commit
[ interfaces ethernet eth2 ]
Adapter does not support changing large-receive-offload settings!
(cherry picked from commit 31169fa8a763e36f6276632139da46b1aca3a7af)
|