There may be adding a static IPv6 default route failed on networks where
router advertisements are also present.
The flow of up an interface is this:
1. ip link set dev $interface up
2. set sysctl config
3. config ip addr
4. config default ip route
After setting the link up, the kernel might learning an address and a
default route from RA before the default route config. The default route
will fail to be added. If the RA route is expired, and not be refreshed
for some reasons，the system looses IPv6 network connectivity.
Proposed fix is to use "route replace" instead of "route add". When the
RA learned route is still present it gets replaced, when it is not present
the route gets added.
Signed-off-by: Kunkun Li <likunkun@bytedance.com>
the following config was broken:
auto swp1
iface swp1
address 10.128.141.37/26
broadcast 10.128.141.63
error: netlink: swp1: cannot add address 10.128.141.37/26 dev swp1: 'str' object has no attribute 'packed'
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>
in the case of ifreload bridge.py:get_dependent is entered twice,
once for the old ifaceobjs and once for the new ones. Thus adding
bridges twice to the list. Having a set will prevent this issue.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
This is to make it consistent with default entries added
by control plane (eg FRR E-VPN)
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
To change the mac address of the device we need to set it down,
then make the change, then bring it back up. Thus we don't need
to check the cache before bringing the device back up.
Also adding a TODO: link_up/down should check if we are running
in a batch context, if so the cache shouldn't be checked to avoid
situation like this.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
