The policy bridge_set_static_mac_from_port was added to ifupdown2 back when we didn't
support a mix of traditional and vlan-aware bridges. The code wasn't revisited after
such config was allowed on the system.
how to repro:
- set bridge_set_static_mac_from_port=yes in module_globals of:
/var/lib/ifupdown2/policy.d/bridge.json
auto br1
iface br1
bridge-vlan-aware no
bridge-stp off
bridge-ports swp1
auto bridge
iface bridge
bridge-ports swp7
bridge-vids 10
bridge-vlan-aware yes
auto vlan10
iface vlan10
address 192.168.0.20/32
vlan-id 10
vlan-raw-device bridge
br1 and bridge will share the same mac address (swp1's mac).
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
When clagd anycast ip configuration changes on an existing setup, we have two issues:
- populate_dependency_info is run twice (in the ifreload case), first on the new
ifaceobjs, then on the old ifaceobjs. Thus hitting vxlan.get_dependent_ifacenames twice
where vxlan._clagd_vxlan_anycast_ip is set (the first time properly, then reset to it's
old value).
The fix: add a "old_ifaceobjs" flag to avoid resetting vxlan._clagd_vxlan_anycast_ip
- when clagd anycast ip changes, clagd also updates the vxlan's ip but there's a chance
that the ifupdown2 cache won't get the netlink notification in time before UP ops are
running on the vxlans, running on a stale cache is no bueno.
The fix: add additional checks to see if we should trust the cache of not.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
make sure to convert the mtu received via policy file back to string
before using it in the bridge module.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
we need to keep track of how many vlan-aware bridge we have in the user
configuration without having to loop over all ifaceobjs again. So we
store their name as they go through get_dependent_ifacenames
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
User may want to have persistent name of dummy port if
"bridge-always-up" option is enabled.
Now the name can be defined in "bridge_always_up_dummy_brport" policy
for bridge module.
Signed-off-by: Alexander Petrovskiy <alexpe@nvidia.com>
Enabling this attribute on a bridge will
enslave a dummy interface to the bridge
example:
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-always-up yes
bridge-ports vni42
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
* master:
addons: address: process MTU before addrgen and adddresses
ifupdownmain: support for marking interfaces as mgmt interfaces
addons: bridge: fix TypeError: sequence item 0: expected string, int found
addons: bridge: set bridge MTU after bridge creation addons: bridge: get bridge MTU from address policy not bridge
addons: mstpctl: check mstpctl-stp and bridge-stp and fix bridge cache update
lib: nlcache: fix dry_run exception
addons: address: add support for a separate default mtu policy for eth interfaces
debian: changelog: new 2.0.2-1 entry
addons: ethtool: add support for "ethtool_ignore_errors" policy
LinkUtils: mac_str_to_int: fix string to int conversion
addons: dhcp: if mgmt vrf context exec dhclient in default vrf
When an stp is enabled on an existing bridge mstpctl attributes are not always
configured by ifreload. This is due to a timing issue (cache) and some issue in
the mstpctl addon.
- Cache: when changing an existing bridge (done via netlink) we wait for the
kernel ack but we don't update our current cache with the new bridge attributes
This is bad because it means that the bridge cache data are stale until we
receive the notification from the kernel.
- Mstp addon: mstpctl-stp was deprecated in favor of bridge-stp, but in some
place, the mstpctl.py code checks for mstpctl-stp but not for bridge-stp. This
commit fixes the area related to this issue but this should be revisited in
a later commit
Ticket: CM-28951
Reviewed By: Roopa
Testing Done: precommit, smoke, evpn-smoke
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-28312
Testing Done: Test from the ticket
error: link_set_bridge_info_data_dry_run() takes exactly 3 arguments (4 given)
error: link_set_brport_with_info_slave_data_dry_run() got an unexpected keyword argument 'kind'
seems like when updating a method, it's associated dry-run method wasn't
updated accordingly. Maybe there is a way to programmatically check that
I will look into it.
warning: bridge: skipping port X invalid ether addr
warning: interface not recognized - please check interface configuration
Won't show on dry-run anymore
Log info for commands executed with utils.exec_command() weren't prefixed with
DRY-RUN.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
error: link_set_bridge_info_data_dry_run() takes exactly 3 arguments (4 given)
error: link_set_brport_with_info_slave_data_dry_run() got an unexpected keyword argument 'kind'
seems like when updating a method, it's associated dry-run method wasn't
updated accordingly. Maybe there is a way to programmatically check that
I will look into it.
warning: bridge: skipping port X invalid ether addr
warning: interface not recognized - please check interface configuration
Won't show on dry-run anymore
Log info for commands executed with utils.exec_command() weren't prefixed with
DRY-RUN.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
The bridge-ports-condone-regex option can be used to tell ifupdown2 to let
some bridge member ports alone and do not remove them on ifreload runs.
This might come in handy when running a KVM (or any other virtualization
system) host with a bridged network setup.
Before this option, ifupdown2 would either complain about not existing
member ports when setting up the bridge (if all VM interfaces were to
be specified in /etc/network/interfaces) or remove any VM interface
from a bridge if it was not specified in /e/n/i.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Co-authored-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
On ifreload (down ops) we need to purge the cache entry of the bridge and its upper devices
to avoid stale values in our cache.
ifup this config, then remove bridge-vids 20, ifreload: since the bridge is removed because
of ifreload_down_changed=1, we need torecreate the vlan bridge.10 and it's configuration, the
cache is stale. We need to clear it to remove the ip 10.10.10.10/32.
auto bridge
iface bridge
bridge-ports swp1 swp2
bridge-vids 10 20
bridge-vlan-aware yes
auto swp1
iface swp1
link-speed 10000
auto swp2
iface swp2
auto bridge.10
iface bridge.10
address 10.10.10.10/32
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
