| 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)
|
|
(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)
|
|
VLAN isolation can not be "set" when interface is of type wifi.
(cherry picked from commit 1ceaed55a629c92cf42baccdef4106e8d0e4914e)
|
|
|
|
(cherry picked from commit e1debb1b57a445fa2357f7dbb5b3f04383f8b1e3)
|
|
It is easier to backport the entire vyos.ifconfig library from 1.4 instead of
backporting single pieces which are required to add new feature to the tunnel
interface section.
In addition that both libraries are now back in sync it will become much easier
to backport any other new feature introduced in VyOS 1.4!
|
|
When a VIF/VLAN interface is placed in admin down state but the lower
interface, serving the vlan, is moved from admin down -> admin up, all its
vlan interfaces will be placed in admin up state, too.
This is bad as a VLAN interface will become admin up even if its specified as
admin down after a reboot.
To reproduce:
set interfaces ethernet eth1 vif 20 disable
set interfaces ethernet eth1 disable
commit
delete interfaces ethernet eth1 disable
commit
Now check the interface state and it returns UP,LOWER_UP
7: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:50:56:b3:09:07 brd ff:ff:ff:ff:ff:ff
inet6 fe80::250:56ff:feb3:907/64 scope link
valid_lft forever preferred_lft forever
(cherry picked from commit 49bc3f1e3ff8416908fc986bb60b444a75a1722d)
|
|
|
|
setting and streamline the code
|
|
`vlan_filter` to avoid redundant paths
|
|
|
|
|
|
|
|
In the implementation of T3042, it will cause two problems:
1. Even if VLAN awareness is not enabled, the VLAN settings of the
vlan filter will be modified. When the bridge member has a WLAN interface,
the error is exposed, so repair it here. You should not modify the
related settings when the VLAN awareness mode is not enabled
2. Even if VLAN awareness is not enabled, the VLAN settings of the
vlan filter will be modified. When the bridge member has a WLAN interface,
due to special settings, the bridge mode cannot be entered and the settings
cannot be completed directly. Therefore, the WLAN interface should be rejected
Enter the bridge with VLAN awareness
|
|
In #601, I provided a basic patch. Under this patch, I rely on vif to
detect the vlan id range that the bridge should flow through,
which may lead to greater redundancy in the configuration,
so I am considering detecting effective vlan filters In setting the range
of vlan id that is required to flow through the bridge,
I use set() to complete the deduplication of this vlan id
and set it to the bridge uniformly (at the same time,
I slightly modified the smoke test script)
|
|
1. Due to the previous focus on the implementation of VLAN filter, it was not considered to include MTU settings, which will lead to MTU setting errors in some cases
2. In order to make VLAN aware of the work of the bridge, it is necessary to specify the allowed VLAN ID range for the bridge itself, and forget to join it before
|
|
|
|
|
|
Renamed using snippet below:
----------------------------
for file in $(find . -name "*.py")
do
sed -i "s/vyos_dict_search/dict_search/" $file
done
|
|
almost every interface can be part of a bridge thus the code for changing STP
cost is best part of the Interface() base class itself.
Commit b5ef10cf ("ifconfig: T2985: support on demand bridge creation")
implemented this change but the STP file was not removed on the test devices
causing tests to pass.
|
|
The current implementation for bridge based interfaces has an issue which is
caused by priority inheritance. We always assumed that the bridge interface will
be created last, but this may not be true in all cases, where some interfaces
will be created "on demand" - e.g. OpenVPN or late (VXLAN, GENEVE).
As we already have a bunch of verify steps in place we should not see a bridge
interface leak to the underlaying infrastructure code. This means, whenever an
interface will be member of a bridge, and the bridge does yet not exist, we will
create it in advance in the interface context, as the bridge code will be run
in the same commit but maybe sooner or later.
This will also be the solution for T2924.
|
|
When removing e.g. a macsec interface and also its associated member interface
from the bridge, it will happen that the macsec interface instance is long gone
before we reach the code in the bridge interface which will remove it from the
bridge itself.
When this is the case, we can not call BridgeIf.del_port() as it will throw an
exception that the interface does not exist. We now only remove a bridge member
if the interface in question is still available in the kernel.
|
|
|
|
Commit 29dd5079 ("ifconfig: T2653: remove duplicated code for address flush")
used the class method for address flushing, but it was cvalled in the wrong way.
|
|
|
|
Every derived class must implement update() to set the interfaces admin
up/down state. This is required to prevend extensive link flaps when e.g.
reconfiguring bond interfaces.
|
|
The current VyOS CLI parser code written in Python contains a ton of duplicates
which I can also hold myself accountable for - or maybe mainly me - depends on
the angle of judge.
While providing a new update() method in vyos.ifconfig.interfaces() this is
extended for bridge interfaces in the derived bridge class.
Signed-off-by: Christian Poessinger <christian@poessinger.com>
|
|
|
|
|
|
__init__ should be added to a derived class only if it does work in the ctor.
|
|
|
