the following config was broken:
auto swp1
iface swp1
address 10.128.141.37/26
broadcast 10.128.141.63
error: netlink: swp1: cannot add address 10.128.141.37/26 dev swp1: 'str' object has no attribute 'packed'
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
[12:57:29] root:~ # ifquery -a
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto swp1
iface swp1
post-up ip link set dev swp1 down
auto swp2
iface swp2
link-down yes
auto swp3
iface swp3
link-down no
auto swp4
iface swp4
[12:57:29] root:~ #
[12:57:29] root:~ #
[12:57:30] root:~ #
[12:57:30] root:~ # ifquery -ac
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp [pass]
auto swp1
iface swp1 (link is down) [fail]
post-up ip link set dev swp1 down []
auto swp2
iface swp2 [pass]
link-down yes [pass]
auto swp3
iface swp3 [pass]
link-down no [pass]
auto swp4
iface swp4
[12:57:31] root:~ #
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>
the mcast group set code was not using the right api
to get mcast groups.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
'bridge flood macs are deleted everytime ifreload is triggered even without any changes to e/n/i config'
this was happening because ifupdown2 was checking the live fdb entries and calculating the delta between
the new and old config. Now we are simply checking the old and new ifupdown2 (/e/n/i) config to avoid
messing with macs added by the control plane
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
fdb entries can be added by FRR, so we won't be checking the running
state if there's no record of a user configuration in /e/n/i
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Currently mixing SVDs and TVDs on the same system is not supported,
regardless of whether they are in the same vlan-aware bridge or
across different ones. NVUE will configure all VNIs as SVDs by
default so this would hopefully only arise if a user edits
/etc/network/interfaces and manages their configuration with ifupdown2.
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>
This is to make it consistent with default entries added
by control plane (eg FRR E-VPN)
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
To change the mac address of the device we need to set it down,
then make the change, then bring it back up. Thus we don't need
to check the cache before bringing the device back up.
Also adding a TODO: link_up/down should check if we are running
in a batch context, if so the cache shouldn't be checked to avoid
situation like this.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
The pre-mature setting of mcast fdbs led to inconsistent state in
mcast grp registration resulting in a deadlock seen in #2638104
more kernel changes towards #2638104 are in progress
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
vxlan-mcastgrp-map config enhancements:
- support for multi-line vxlan multicast group config.
- support for vni range config.
- support for mcast grp range config.
- support for mcast network config.
Example:
vxlan-mcastgrp-map 10001=239.5.2.1
vxlan-mcastgrp-map 10002=239.5.2.2
vxlan-mcastgrp-map 10003=239.5.2.3
vxlan-mcastgrp-map 10005-10008=239.10.39.121
vxlan-mcastgrp-map 10010-10020=239.10.39.152-239.10.39.162
vxlan-mcastgrp-map 10005-10002=239.10.0.0/24
Reviewed-by: Julien Fortin <jfortin@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>, Scott Laffer <slaffer@nvidia.com>
Signed-off-by: Scott Laffer <slaffer@nvidia.com>, Quentin Zilberberg <qzil@nvidia.com>
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>
updating an existing singe-vxlan-device is not supported yet, we should warn
the user accordingly.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.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>
