Rename method "addr_metric_support" to prevent any misunderstanding/clash
with field "ADDR_METRIC_SUPPORT" defined on line 80
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
/etc/network/interfaces
-----------------------
auto eth0.100
iface eth0.100
vlan-protocol 802.1ad
current
-------
ifquery -a -c
auto eth0.100
iface eth0.100 [pass]
new
---
ifquery -a -c
auto eth0.100
iface eth0.100 [pass]
vlan-protocol 802.1ad [pass]
Fake bridge are are ovsbridge child of a parent bridge with a specific vlan tag.
```
auto br-parent
iface br-parent inet manual
ovs_type OVSBridge
auto br-fakev10
iface br-fakev10 inet manual
ovs_type OVSBridge
ovs_bridge br-parent
ovs_options br-parent 10
```
If the output of the subprocess is empty, then an empty <bytes> object
is returned (b''), and not decoded into an empty <string> object.
This may result in errors such as:
info[109734]: executing /bin/ip -6 addr show eth0
networking[109734]: error: eth0: cannot use a string pattern on a
bytes-like object
error[109734]: eth0: cannot use a string pattern on a bytes-like object
As of now, the distutils is deprecated with removal planned for
python 3.12.
The recommended way is to use setuptools which is an enhanced
alternative to distutils maintained by the python packaging authority.
This commit replace with setuptools the distutil import inserted in the
8126ef0c00eb8e2faae2cf1ca9fbaf25c10582cd commit.
This commit also update the debian control runtime dependency.
distutils: https://docs.python.org/3/library/distutils.html
setuptools: https://setuptools.pypa.io/en/latest/
gvgen module require the six module from python3-six package.
This new dependency is only necessary for python2/python3 cross
compatibility on dict.iteritems() (py2) vs dict.items() (py3).
ifupdown2 does not support python2 so we could replace every iteritems
occurrences to it's python3 format but this means the gvgen module will
diff from upstream.
The simplest way is to make ifupdown depends on python3-six.
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>
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>
