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.
AttributeGeneric cannot be used unless having it's length defined.
This change allow address flags such as optimistic, nodad or others
to be set with the add_attribute packet method.
