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>
Three issues:
- when `hwaddress` is removed from an SVI (on top of a bridge), the svi
mac is not resetted back to the bridge mac: fixed
- when `hwaddress` is used on an svi, stale fdb enties were added with the
bridge mac: fixed
- on ifdown we were leaving a leftover fdb entry on the deleted svi: fixed
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
When a policy dhcp-wait is false the dhcp client is run directly in
background.
But, in most cases, the client won't have the time to find an address
before a check occur.
This is making the client being killed nearly every time.
The obvious solution here is to not check ips differences when no-wait
is asked by the policy.
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>
Upon ipv6_dad_handling_enabled module global parameter set to true, the
address addon will handle ipv6 dad tentatives by either
* set nodad when adding an ipv6 address
* waiting for dad to finish or warn of a timeout
This handling should be quick close to the ifupdown process.
On older ubuntu version bridge_binding is not supported, we can't rely
on `ip link help` to detect this. We have manually check if the first
netlink request is rejected then retry with iproute2.
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>
