On bond creation and update, ifupdown2 directly caches the netlink
object sent to the kernel. If the bond already exists it overrides
the existing cached object. If the existing bond was enslaved to a
bridge, some bridge vlan data would get purged because the new
netlink object didn't have the IFLA_MASTER attribute (thus tricking
the cache into thinking that the bond got unslaved from the bridge).
Here is a snippet of the bond013 /en/i config in the first topology:
auto bond013
iface bond013
bond-slaves swp1s3
es-sys-mac 44:38:39:FF:00:02
bridge-vids 101-144
bond-lacp-bypass-allow yes
mstpctl-portadminedge yes
mstpctl-bpduguard yes
And here in the second topology:
auto bond013
iface bond013
bond-slaves swp1s3
es-sys-mac 44:38:39:FF:00:01
bridge-vids 201-210
bond-lacp-bypass-allow yes
mstpctl-portadminedge yes
mstpctl-bpduguard yes
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
For some reason es-sys-mac (IFLA_BOND_AD_ACTOR_SYSTEM) is not part
of the netlink dump if requested by non-root user. This commit adds
a log info and will ignore es-sys-mac in that case.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
It is only valid for balance-rr and balance-xor.
One Example is:
auto bond0
iface bond0 inet
bond-slaves ens21 ens22
bond-mode balance-rr
bond-arp-interval 100
bond-arp-ip-target 8.8.8.8
address 10.10.10.1/24
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
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>
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>
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>
ES bonds have the same "init state" requirements as CLAG bonds -
1. A bond needs to be designated as an "es-bond" for this purpose.
For clag-bonds we used "clag-id" attr (to designate a bond as a "clag-bond").
For ES bonds we will use "es-sys-mac" attr.
2. Slaves added to an "ES bond" must have protodown-on.
This is again similar to CLAG bonds
3. And vice-versa i.e. when a slave is removed from an "es-bond",
protodown-on must be cleared.
4. When es-sys-mac is first set on a bond, all the bond-slaves must be
placed in "protodown-on" state. This is needed whether FRR is running at that point or not.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Python3 sets are using the python hash seed to generate random hashes
which makes the sets ordering different everytime. In our case we need
to honor the user configuration (first device should be enslaved first)
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
This is a major update coming all at once from master-next branch
master-next branch was started with --orphan option which is basically a new
branch without history.
The major changes are:
- repackaging
- cleanup the directory tree
- rewritte setup.py to allow install from deb file or pypi (pip install)
- add a Makefile to make things (like building a deb) easier
- review all debian files
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
