Old code was a bit messy and all over the place. This
resulted in a loophole breaking sync between bridge-learning
and vxlan-learning. This patch simplifies the existing code
and fixes the bug.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
if not specified by the user vxlan brport learning is controlled by the
bridge_vxlan_port_learning policy (on by default).
4.4 introduced vxlan-learning off via policy. The syncing code between
bridge-learning and vxlan-learning was incomplete and was written at the
time when we didn't have a default vxlan-learning policy. This patch fixes
the sync-ing gap and makes sure vxlan-learning is sync'd with bridge-learning
which wasn't always the case before.
for every vxlan brport BRPORT_LEARNING is turned on
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
since we added the debug_handler we are not setting any level
on the root logger, the level is set for each individual handler
log_error and log_warning were using traceback.print_stack and print_exc
which and also only checked the rooter logger's level via getEffectiveLevel
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Due to missing checks, ifupdown2 may display the following warning for
static vxlan configs.
"warning: possible mis-configuration detected: l2-vni configured
with bridge-learning ON while EVPN is also configured - these two
parameters conflict with each other."
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
error: vx-1002: misconfiguration detected: maximum vni allowed per bridge (bridge) svi (1000) is limited to 1 (policy: 'bridge_vni_per_svi_limit')
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
after a successful mac change we should override our cache so that we don't
keep stale values in cache (in case the cache is queried before the kernel
notification arrives)
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
in the case of ifreload bridge.py:get_dependent is entered twice,
once for the old ifaceobjs and once for the new ones. Thus adding
bridges twice to the list. Having a set will prevent this issue.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
- create single vxlan device with vnifilter flag
- install vni filter with vnis from bridge-vxlan-vni-map
- vni filter can only be applied when the vxlan interface
is in down state
- toggling of vni filter is unsupported (maybe in the future)
- vni filter on a single vxlan or collect metadata/external
device is a new kernel feature yet to be upstreamed
- move vlan/vni id math helpers to utils.py
Reviewed-by: Julien Fortin <jfortin@nvidia.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Instead of exploding vlans and vnis ranges we can simply pass those ranges to iproute2
which will reduce the load on ifupdown2 side and scale better
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
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>
