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>
context:
The IP address 169.254.0.1 is used by BGP unnumbered as an onlink
next-hop for IPv4 prefixes. When this is configured on the box, it
causes major issues which are very difficult to diagnose a debug.
It would be great if ifupdown2 could block this from being installed
on any interface as an address or address-virtual.
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>
check if the bond mac address is correctly inherited from it's
first slave. There's a case where that might not be happening:
$ ip link show swp1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show swp2 | grep ether
link/ether 08:00:27:04:d8:02 brd ff:ff:ff:ff:ff:ff
$ ip link add dev bond0 type bond
$ ip link set dev swp1 master bond0
$ ip link set dev swp2 master bond0
$ ip link show bond0 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link add dev bond1 type bond
$ ip link set dev swp1 master bond1
$ ip link show swp1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show swp2 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show bond0 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show bond1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$
ifupdown2 will automatically correct and fix this unexpected behavior
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
with kernel 4.19, slaves that are removed from a bond will be
admin down, this patch makes sure that the links are admin up
if they are part of the "auto" class and link-down yes is not set
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
When creating a bond, we first use a netlink call, if that
call fails we try to create and setup the bond via sysfs.
If the bond name is longer than 15 chars the netlink call
will fail, we will then enter the sysfs path which creates
the bond by writing to /sys/class/net/bonding_masters. In
this case the bonding driver will simply truncate the bond
name to fit into the 15 chars limit.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
From Mike Manning:
In the case of vlan filtering on bridges, the bridge may also have the
corresponding vlan devices as upper devices. Currently the link state
of vlan devices is transferred from the lower device. So this is up if
the bridge is in admin up state and there is at least one bridge port
that is up, regardless of the vlan that the port is a member of.
The link state of the vlan device may need to track only the state of
the subset of ports that are also members of the corresponding vlan,
rather than that of all ports.
Add a flag to specify a vlan bridge binding mode, by which the link
state is no longer automatically transferred from the lower device,
but is instead determined by the bridge ports that are members of the
vlan.
----
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
nlcache used a set to keep a master's slave list. This wasn't the right
choice as sets can't guarantee ordering. We need to keep an ordered list
of ports.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
This prevents DHCP requests failures taking time during
boot if the interface isn't up yet. If the interface is
down, dhclient will fail to send packets.
At boot-time, enslaving an interface to vrf flaps it. By
waiting for the interface to come back up before starting
dhclient reduces time to boot.
Reviewed-by: CCR-10987
Closes: CM-32460
Co-developed-by: Nilesh Shinde <nilesh@nvidia.com>
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
since we've updated ifupdown2 to pytho3 the error
message should mention python3-mako and not
python-mako (python2)
Ticket: CM-29621
Reviewed By: Roopa
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
