python2's ifupdown2 used python-gvgen to output the dependency graph in dot
format. There's not python3 version of that package available in debian.
Resulting in: error: main exception: name 'GvGen' is not defined
The package is in fact a single class that is already compatible with python3
According to the license (MIT) we can pull in the code in our own tree.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Current design destroys existing tunnel when a config
change is detected. This behaviour causes traffic loss.
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>
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>
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>
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>
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>
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>
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>
- 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>
Instead of exploding vlans and vnis ranges we can simply pass those ranges to iproute2
which will reduce the load on ifupdown2 side and scale better
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
context:
The IP address 169.254.0.1 is used by BGP unnumbered as an onlink
next-hop for IPv4 prefixes. When this is configured on the box, it
causes major issues which are very difficult to diagnose a debug.
It would be great if ifupdown2 could block this from being installed
on any interface as an address or address-virtual.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
we need to keep track of how many vlan-aware bridge we have in the user
configuration without having to loop over all ifaceobjs again. So we
store their name as they go through get_dependent_ifacenames
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
