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>
On a MLAG configured switch, only one vlan aware bridge is supported
The clag module need to access the full list of ifaceobjs. This is a
bit breaking the existing segmentation, not great but would otherwise
require a huge refactoring/rework.
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>
As seen in the example below we are seeing a corner case, first the user
/e/n/i is configured without 'hwaddress', then it is used to fix the svi
mac address. The current code only checks for the statemanager for old
'hwaddress' attribute but couldn't find any. Now we save the mac addr
before updating it, so we can later clear it from the fdb.
$ cat a
auto eth0
iface eth0 inet dhcp
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports vx-1000
bridge-stp on
bridge-vids 1000 1002 1004 1006 1008
bridge-pvid 1
auto vx-1000
iface vx-1000
vxlan-id 1000
bridge-access 1000
vxlan-local-tunnelip 27.0.0.11
bridge-learning off
bridge-arp-nd-suppress on
mstpctl-portbpdufilter yes
mstpctl-bpduguard yes
mtu 9152
auto vlan1000
iface vlan1000
address 45.0.0.2/24
vlan-id 1000
vlan-raw-device bridge
address-virtual 00:00:5e:00:01:01 45.0.0.1/24
vrf vrf1
auto vrf1
iface vrf1
vrf-table auto
$
$
$ cat b
auto eth0
iface eth0 inet dhcp
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports vx-1000
bridge-stp on
bridge-vids 1000 1002 1004 1006 1008
bridge-pvid 1
auto vx-1000
iface vx-1000
vxlan-id 1000
bridge-access 1000
vxlan-local-tunnelip 27.0.0.11
bridge-learning off
bridge-arp-nd-suppress on
mstpctl-portbpdufilter yes
mstpctl-bpduguard yes
mtu 9152
auto vlan1000
iface vlan1000
address 45.0.0.2/24
hwaddress 00:02:00:aa:aa:aa
vlan-id 1000
vlan-raw-device bridge
address-virtual 00:00:5e:00:01:01 45.0.0.1/24
vrf vrf1
auto vrf1
iface vrf1
vrf-table auto
$
$
$ rm /etc/network/interfaces ; ln -s `pwd`/a /etc/network/interfaces ; ifreload -a ; rm /etc/network/interfaces ; ln -s `pwd`/b /etc/network/interfaces ; (ifreload -av |& grep vlan | grep 1000)
info: bridge: netlink: bridge vlan add vid 1000 dev bridge
info: vlan1000: netlink: ip link set dev vlan1000 down
info: vlan1000: netlink: ip link set dev vlan1000 address 00:02:00:aa:aa:aa
info: vlan1000: netlink: ip link set dev vlan1000 up
info: writing '1' to file /proc/sys/net/ipv4/conf/vlan1000/arp_accept
info: executing /sbin/bridge fdb del 4a:b3:1e:45:bf:bf dev bridge vlan 1000 self
info: executing /sbin/bridge fdb replace 00:02:00:aa:aa:aa dev bridge vlan 1000 self
info: executing /sbin/bridge fdb replace 00:00:5e:00:01:01 dev bridge vlan 1000 self
$
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Context:
"user accidentally disabled ip4 and ip6 forwarding on the L3-SVI for all VRF's.
we should add a check in ifupdown2 to warn user this is a bad config (symmetric
routing will not work if routing is disabled in this way)."
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
patch adds the following warning when it detects a vlan-id misconfiguration
error: vlan13: cannot change vlan-id to 13: operation not supported. Please delete the device with 'ifdown vlan13' and recreate it to apply the change.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
This allows syntax checking to pass for fields like vxlan-ttl/vxlan-tos
which can be a number in a range OR a string value representing a special
meaning (0-255 or "auto", for instance). Without this, you can only pass
a --syntax-check for such fields if your value is one of those literally
specified because, for instance, "64" is not "auto", "0", or "255":
invalid value "64": valid attribute values: ['0', '255']
info: exit status 1
Note that _applying_ such configuration still works, because netlink's
acceptance criteria are independent of ifupdown2's.
fix vxlan-tos inherit = 1 (was set to 0)
and other fixes to make sure we don't unnecessarily set
those attributes on vxlan creation
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>
