A missing "+1" in a loop condition prevents ifupdown2 from creating
N vrfs up to vrf-max-count. We are stuck at vrf-max-count - 1
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
we have an automation test that adds a vrf named "VRF.TEST":
$ ifquery -a
auto VRF.TEST
iface VRF.TEST
vrf-table auto
$ ifup -a
error: could not determine vlanid
warning: error while writing to file /sys/class/net/VRF.TEST/mtu: [Errno 22] Invalid argument
$
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Due to missing checks, ifupdown2 may display the following warning for
static vxlan configs.
"warning: possible mis-configuration detected: l2-vni configured
with bridge-learning ON while EVPN is also configured - these two
parameters conflict with each other."
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
error: vx-1002: misconfiguration detected: maximum vni allowed per bridge (bridge) svi (1000) is limited to 1 (policy: 'bridge_vni_per_svi_limit')
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>
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>