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>
The pre-mature setting of mcast fdbs led to inconsistent state in
mcast grp registration resulting in a deadlock seen in #2638104
more kernel changes towards #2638104 are in progress
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
vxlan-mcastgrp-map config enhancements:
- support for multi-line vxlan multicast group config.
- support for vni range config.
- support for mcast grp range config.
- support for mcast network config.
Example:
vxlan-mcastgrp-map 10001=239.5.2.1
vxlan-mcastgrp-map 10002=239.5.2.2
vxlan-mcastgrp-map 10003=239.5.2.3
vxlan-mcastgrp-map 10005-10008=239.10.39.121
vxlan-mcastgrp-map 10010-10020=239.10.39.152-239.10.39.162
vxlan-mcastgrp-map 10005-10002=239.10.0.0/24
Reviewed-by: Julien Fortin <jfortin@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>, Scott Laffer <slaffer@nvidia.com>
Signed-off-by: Scott Laffer <slaffer@nvidia.com>, Quentin Zilberberg <qzil@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
- create single vxlan device with vnifilter flag
- install vni filter with vnis from bridge-vxlan-vni-map
- vni filter can only be applied when the vxlan interface
is in down state
- toggling of vni filter is unsupported (maybe in the future)
- vni filter on a single vxlan or collect metadata/external
device is a new kernel feature yet to be upstreamed
- move vlan/vni id math helpers to utils.py
Reviewed-by: Julien Fortin <jfortin@nvidia.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
