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
8126ef0c00 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/
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>
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>
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.
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>
As seen in the example below we are seeing a corner case, first the user
/e/n/i is configured without 'hwaddress', then it is used to fix the svi
mac address. The current code only checks for the statemanager for old
'hwaddress' attribute but couldn't find any. Now we save the mac addr
before updating it, so we can later clear it from the fdb.
$ cat a
auto eth0
iface eth0 inet dhcp
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports vx-1000
bridge-stp on
bridge-vids 1000 1002 1004 1006 1008
bridge-pvid 1
auto vx-1000
iface vx-1000
vxlan-id 1000
bridge-access 1000
vxlan-local-tunnelip 27.0.0.11
bridge-learning off
bridge-arp-nd-suppress on
mstpctl-portbpdufilter yes
mstpctl-bpduguard yes
mtu 9152
auto vlan1000
iface vlan1000
address 45.0.0.2/24
vlan-id 1000
vlan-raw-device bridge
address-virtual 00:00:5e:00:01:01 45.0.0.1/24
vrf vrf1
auto vrf1
iface vrf1
vrf-table auto
$
$
$ cat b
auto eth0
iface eth0 inet dhcp
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports vx-1000
bridge-stp on
bridge-vids 1000 1002 1004 1006 1008
bridge-pvid 1
auto vx-1000
iface vx-1000
vxlan-id 1000
bridge-access 1000
vxlan-local-tunnelip 27.0.0.11
bridge-learning off
bridge-arp-nd-suppress on
mstpctl-portbpdufilter yes
mstpctl-bpduguard yes
mtu 9152
auto vlan1000
iface vlan1000
address 45.0.0.2/24
hwaddress 00:02:00:aa:aa:aa
vlan-id 1000
vlan-raw-device bridge
address-virtual 00:00:5e:00:01:01 45.0.0.1/24
vrf vrf1
auto vrf1
iface vrf1
vrf-table auto
$
$
$ rm /etc/network/interfaces ; ln -s `pwd`/a /etc/network/interfaces ; ifreload -a ; rm /etc/network/interfaces ; ln -s `pwd`/b /etc/network/interfaces ; (ifreload -av |& grep vlan | grep 1000)
info: bridge: netlink: bridge vlan add vid 1000 dev bridge
info: vlan1000: netlink: ip link set dev vlan1000 down
info: vlan1000: netlink: ip link set dev vlan1000 address 00:02:00:aa:aa:aa
info: vlan1000: netlink: ip link set dev vlan1000 up
info: writing '1' to file /proc/sys/net/ipv4/conf/vlan1000/arp_accept
info: executing /sbin/bridge fdb del 4a:b3:1e:45:bf:bf dev bridge vlan 1000 self
info: executing /sbin/bridge fdb replace 00:02:00:aa:aa:aa dev bridge vlan 1000 self
info: executing /sbin/bridge fdb replace 00:00:5e:00:01:01 dev bridge vlan 1000 self
$
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Context:
"user accidentally disabled ip4 and ip6 forwarding on the L3-SVI for all VRF's.
we should add a check in ifupdown2 to warn user this is a bad config (symmetric
routing will not work if routing is disabled in this way)."
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>
Openvswitch already manage mtu if ovs-mtu is defined.
(Ovs manage mtu in userland, and sync mtu for some interfaces in kernel).
If mtu is changed by address module, before the ovs userland mtu,
this give packets drop.
* master:
addons: address: process MTU before addrgen and adddresses
ifupdownmain: support for marking interfaces as mgmt interfaces
addons: bridge: fix TypeError: sequence item 0: expected string, int found
addons: bridge: set bridge MTU after bridge creation addons: bridge: get bridge MTU from address policy not bridge
addons: mstpctl: check mstpctl-stp and bridge-stp and fix bridge cache update
lib: nlcache: fix dry_run exception
addons: address: add support for a separate default mtu policy for eth interfaces
debian: changelog: new 2.0.2-1 entry
addons: ethtool: add support for "ethtool_ignore_errors" policy
LinkUtils: mac_str_to_int: fix string to int conversion
addons: dhcp: if mgmt vrf context exec dhclient in default vrf
classic ifupdown don't change forwarding value if not defined in /etc/network/interfaces (don't even support it).
Currently ifupdown2 behaviour is to turn forwarding off when not defined. (and break sysctl manual enabling (net.ipv4.ip_forward = 1, net.ipv4.conf.all.forwarding = 1, net.ipv4.conf.default.forwarding = 1
on restart or reload).
Better to not change value when not defined, and keep user manual config.
As mentioned in a previous commit:
python3 ipaddress behave differently from python2-ipaddr, this is
a serious problem for us since it breaks most of the ip addresses
code.
>>> import ipaddress
>>> ipaddress.ip_network("10.10.10.242/10", False)
IPv4Network('10.0.0.0/10')
This is a problem for us, so we need to use a custom IPNetwork object.
Our custom IPNetwork object uses ipaddress.IPAddress under the hood
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
IPNetwork doesn't exists anymore and is replaced by ip_network. IPv?Network (4 and 6)
objects take an optional argument "strict" that defaults to True. If strict is set
and the ip address has the host bit set it will raise an exception. This is bad
for ifupdown2, so we need to replace all calls to IPNetwork and IPv?Network with
function who will set strict to False. That way we can limit the number of changes
for this patch.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
