Old code was a bit messy and all over the place. This
resulted in a loophole breaking sync between bridge-learning
and vxlan-learning. This patch simplifies the existing code
and fixes the bug.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
if not specified by the user vxlan brport learning is controlled by the
bridge_vxlan_port_learning policy (on by default).
4.4 introduced vxlan-learning off via policy. The syncing code between
bridge-learning and vxlan-learning was incomplete and was written at the
time when we didn't have a default vxlan-learning policy. This patch fixes
the sync-ing gap and makes sure vxlan-learning is sync'd with bridge-learning
which wasn't always the case before.
for every vxlan brport BRPORT_LEARNING is turned on
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
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>
since we added the debug_handler we are not setting any level
on the root logger, the level is set for each individual handler
log_error and log_warning were using traceback.print_stack and print_exc
which and also only checked the rooter logger's level via getEffectiveLevel
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Prior commit (from me) that changed ipv6_addrgenmode for VRRP macvlan
interfaces from RANDOM --> NONE incorrectly disabled this for vrrp6.
The IPv6 link-local address is used as the SIP for vrrp6 hellos, so we
need to make sure that we are only setting addrgenmode to NONE for vrrp4.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
A VRRP macvlan interface should only have addresses matching the
VIP defined by the user. This change ensures we set ipv6 addrgenmode
to none, that way there won't be any unexpected (from user standpoint)
ipv6 link-local addresses to cause confusion or erroneous Type-2 EVPN
routes (in the case of advertise-default-gw with VRRP instead of VRR)
that advertise IP addresses that don't represent a VIP.
Signed-off-by: Trey Aspelund <taspelund@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
the policy l3_intf_arp_accept now accepts boolean value True(1)/False(0) as well
as normal arp_accept values
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
The extra try/except are necessary just in case something goes wrong
we still want to go through the entire list of extra log dir present
on the system.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
enable persistent ifupdown2 debug logs
ifupdown2 will keep debug logs in /etc/network/ifupdown2/logs
by default the last 42 configurations logs will be kept.
yes - (default) enable persistent logging (42 configs)
no - disable persistent logging
[2-9]+ - specify how many configuration logs should be stored
enable_persistent_debug_logging=yes
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
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.
