summaryrefslogtreecommitdiff
path: root/python/vyos/ifconfig/bridge.py
AgeCommit message (Collapse)Author
2022-06-29bridge: add option to enable/disable IGMP/MLD snoopingYuxiang Zhu
This PR adds an config option to enable/disable IGMP/MLD snooping. ``` set interfaces bridge brN igmp snooping ```
2022-02-16wireless: T4240: bugfix interface bridgingChristian Poessinger
VLAN isolation can not be "set" when interface is of type wifi.
2021-08-21vyos.ifconfig: bridge: remove missleading comment in update()Christian Poessinger
2021-03-19bridge: T3415: add port isolation / private-vlan optionChristian Poessinger
Private VLAN, also known as port isolation, is a technique in computer networking where a VLAN contains switch ports that are restricted such that they can only communicate with a given "uplink". The restricted ports are called "private ports". Each private VLAN typically contains many private ports, and a single uplink. The uplink will typically be a port (or link aggregation group) connected to a router, firewall, server, provider network, or similar central resource. Q: https://en.wikipedia.org/wiki/Private_VLAN
2021-02-28vif: T3349: use fixed ordering when enabling parent and child interfaceChristian Poessinger
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
2021-02-28vyos.ifconfig: T1579: remove calls to vyos.ifconfig.Interface.get_config()Christian Poessinger
Interface.get_config() was always a pure helper which exposed a "per interface type" dictionary which was then fed by the caller to create interfaces by iproute2 which required additional options during creation time. Such interfaces had been: * tunnel * vxlan * geneve * macsec * wifi * macvlan / pseudo-ethernet The code was always duplicated to convert from the VyOS CLI based get_config_dict() to a dict which can be used to feed iproute2. This path has been removed and we now always feed in the entire dictionary retrieved by get_config_dict() or in the interfaces case, it's high-level wrapper get_interface_dict() to the interface we wan't to create. This also adds the - personally long awaited - possibility to get rid of the derived tunnel classes for e.g. GRE, IPIP, IPIP6 and so on.
2021-01-17bridge: T3137: Fix variable errors in VLAN sensor bridge configuration programjack9603301
2021-01-16bridge: T3137: Support disable native VLANjack9603301
2021-01-15bridge: T3137: Delete blank linesjack9603301
2021-01-15bridge: T3137: Better implementation of VLAN aware Bridgejack9603301
2021-01-15bridge: T3137: Let VLAN aware bridge approach the behavior of professional ↵jack9603301
equipment According to the consensus, the specific behavior of a VLAN aware bridge should conform to the behavior of professional equipment. This commit makes a significant change to the behavior of VLAN aware bridge, and has the following behaviors: 1. Disable `vif 1` configuration 2. When the VLAN aware bridge is enabled, the parent interface is always VLAN 1 3. When `native-vlan` is not configured, the default behavior of the device is `native-vlan 1` 4. The VLAN ids forwarded by the bridge are determined by `vif` 5. It has an `enable-vlan` node to enable VLAN awareness 6. VLAN configuration is allowed only when VLAN aware bridge is activated
2020-12-20wifi: T2875: support bridging of wireless AP interfaceChristian Poessinger
2020-12-13interfaces: T3114: Modify the logic of the second addition to complete the ↵jack9603301
setting and streamline the code
2020-12-13interfaces: T3114: Improve the processing of enabling logic for ↵jack9603301
`vlan_filter` to avoid redundant paths
2020-12-13interfaces: T3114: Fix VLAN-aware bridge setting failurejack9603301
2020-11-23bridge: T2875: handle OS exception when wifi interface does not support bridgingChristian Poessinger
2020-11-21bridge: T3079: bugfix on VLAN 1 is deleted in VLAN-aware bridgesJACK
2020-11-19bridge: T3067: Fix VLAN aware setting failure under WLAN (#613)JACK
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
2020-11-14bridge: T3042: Better fix implementation errorsjack9603301
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)
2020-11-13bridge: T3042: Fix VLAN filter invalid workjack9603301
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
2020-11-10bridge: T3042: Support VLAN filter and VLAN sub-interface on the bridgejack9603301
2020-11-03ifconfig: T2985: fix wireless-bridge creationChristian Poessinger
2020-10-28vyos.util: T2995: rename vyos_dict_search() -> dict_search()Christian Poessinger
Renamed using snippet below: ---------------------------- for file in $(find . -name "*.py") do sed -i "s/vyos_dict_search/dict_search/" $file done
2020-10-18ifconfig: T2985: remove no longer available vyos.ifconfig.stp includeChristian Poessinger
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.
2020-10-17ifconfig: T2985: support on demand bridge creationChristian Poessinger
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.
2020-09-21bridge: ifconfig: T2653: only delete member interfaces which still existChristian Poessinger
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.
2020-08-23T2755: convert jmespath.search() to vyos_dict_search() for performanceChristian Poessinger
2020-07-31ifconfig: T2653: bugfix on wrong flush_addr APIChristian Poessinger
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.
2020-07-30ifconfig: T2653: remove duplicated code for address flushChristian Poessinger
2020-07-25ifconfig: T2653: implement update() in derived classes for admin up/downChristian Poessinger
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.
2020-07-25bridge: ifconfig: T2653: move to get_config_dict()Christian Poessinger
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>
2020-04-08import: T2242: remove all import *Thomas Mangin
2020-03-24ifconfig: T2057: add class RegisterThomas Mangin
2020-03-22ifconfig: T2104: remove superfluous __init__ in derived classesChristian Poessinger
__init__ should be added to a derived class only if it does work in the ctor.
2020-03-06ifconfig: T2104: splt ifconfig.py into multiple filesThomas Mangin