addons: bridge: bridge_vlan_aware_list is now a set()
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.
Julien Fortin [Tue, 2 Mar 2021 12:20:06 +0000 (13:20 +0100)]
iproute2: link_set_address: dont check the cache on link up
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.
$ifup -v vxlan1
...
info: executing /sbin/bridge -force -batch - [vlan add vid 1000-1009 dev
vxlan1
vlan add dev vxlan1 vid 1000-1009 tunnel_info id 1002-1011
vlan add vid 2000-2020 dev vxlan1
vlan add dev vxlan1 vid 2000-2020 tunnel_info id 1998-2018]
...
changes include:
- supporting the new syntax
- moved vlan vni map handling into a utility function
to be used by bridge tunnel_info and vxlan vnifilter
addons: vxlan: add support for vni/IP range and multi lines on SVD mcast group config
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.
Roopa Prabhu [Wed, 24 Mar 2021 21:20:58 +0000 (14:20 -0700)]
addons: vxlan: add support for vni filter on single vxlan device
- 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
Julien Fortin [Tue, 8 Dec 2020 01:36:22 +0000 (02:36 +0100)]
addons: bridge: add multi bridge support when bridge_set_static_mac_from_port=yes
The policy bridge_set_static_mac_from_port was added to ifupdown2 back when we didn't
support a mix of traditional and vlan-aware bridges. The code wasn't revisited after
such config was allowed on the system.
how to repro:
- set bridge_set_static_mac_from_port=yes in module_globals of:
/var/lib/ifupdown2/policy.d/bridge.json
auto br1
iface br1
bridge-vlan-aware no
bridge-stp off
bridge-ports swp1
auto bridge
iface bridge
bridge-ports swp7
bridge-vids 10
bridge-vlan-aware yes
auto vlan10
iface vlan10
address 192.168.0.20/32
vlan-id 10
vlan-raw-device bridge
br1 and bridge will share the same mac address (swp1's mac).
ifupdownmain: add "all" parameter to get_all_ifaceobjs
On a MLAG configured switch, only one vlan aware bridge is supported
The clag module need to access the full list of ifaceobjs. This is a
bit breaking the existing segmentation, not great but would otherwise
require a huge refactoring/rework.
Julien Fortin [Thu, 4 Feb 2021 04:23:22 +0000 (05:23 +0100)]
addons: vxlan: inherit clagd-vxlan-anycast-ip from lo for clag vxlans (introduces old_ifaceobjs to get_dependent_ifacenames)
When clagd anycast ip configuration changes on an existing setup, we have two issues:
- populate_dependency_info is run twice (in the ifreload case), first on the new
ifaceobjs, then on the old ifaceobjs. Thus hitting vxlan.get_dependent_ifacenames twice
where vxlan._clagd_vxlan_anycast_ip is set (the first time properly, then reset to it's
old value).
The fix: add a "old_ifaceobjs" flag to avoid resetting vxlan._clagd_vxlan_anycast_ip
- when clagd anycast ip changes, clagd also updates the vxlan's ip but there's a chance
that the ifupdown2 cache won't get the netlink notification in time before UP ops are
running on the vxlans, running on a stale cache is no bueno.
The fix: add additional checks to see if we should trust the cache of not.
Julien Fortin [Mon, 28 Jun 2021 23:07:48 +0000 (01:07 +0200)]
addons: address: remove stale fdb entry for svi (when hwaddress is used)
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 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
$
$
$ 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
$
addons: address: warn user if L3-SVI is configured with "ip-forward off"
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)."
Julien Fortin [Sat, 12 Dec 2020 00:20:57 +0000 (01:20 +0100)]
addons: vlan: check vlan-id misconfiguration and print warning
patch adds the following warning when it detects a vlan-id misconfiguration
error: vlan13: cannot change vlan-id to 13: operation not supported. Please delete the device with 'ifdown vlan13' and recreate it to apply the change.
Sam Osterkil [Tue, 1 Jun 2021 19:45:34 +0000 (13:45 -0600)]
Support value-in-range with <number> keyword
This allows syntax checking to pass for fields like vxlan-ttl/vxlan-tos
which can be a number in a range OR a string value representing a special
meaning (0-255 or "auto", for instance). Without this, you can only pass
a --syntax-check for such fields if your value is one of those literally
specified because, for instance, "64" is not "auto", "0", or "255":
invalid value "64": valid attribute values: ['0', '255']
info: exit status 1
Note that _applying_ such configuration still works, because netlink's
acceptance criteria are independent of ifupdown2's.
add support for new address policy: 'ip_blacklist'
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.
lib: Addon: add new Bridge class with member "bridge_vlan_aware_list"
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
Julien Fortin [Fri, 2 Oct 2020 12:02:18 +0000 (14:02 +0200)]
addons: bond: bond mac should always be inherited from it's first slave
check if the bond mac address is correctly inherited from it's
first slave. There's a case where that might not be happening:
$ ip link show swp1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show swp2 | grep ether
link/ether 08:00:27:04:d8:02 brd ff:ff:ff:ff:ff:ff
$ ip link add dev bond0 type bond
$ ip link set dev swp1 master bond0
$ ip link set dev swp2 master bond0
$ ip link show bond0 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link add dev bond1 type bond
$ ip link set dev swp1 master bond1
$ ip link show swp1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show swp2 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show bond0 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show bond1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$
ifupdown2 will automatically correct and fix this unexpected behavior
addons: bond: keep link admin up after being removed from bond
with kernel 4.19, slaves that are removed from a bond will be
admin down, this patch makes sure that the links are admin up
if they are part of the "auto" class and link-down yes is not set
Julien Fortin [Mon, 10 Aug 2020 14:02:13 +0000 (16:02 +0200)]
addons: bond: add ifname length check in sysfs back up path
When creating a bond, we first use a netlink call, if that
call fails we try to create and setup the bond via sysfs.
If the bond name is longer than 15 chars the netlink call
will fail, we will then enter the sysfs path which creates
the bond by writing to /sys/class/net/bonding_masters. In
this case the bonding driver will simply truncate the bond
name to fit into the 15 chars limit.
From Mike Manning:
In the case of vlan filtering on bridges, the bridge may also have the
corresponding vlan devices as upper devices. Currently the link state
of vlan devices is transferred from the lower device. So this is up if
the bridge is in admin up state and there is at least one bridge port
that is up, regardless of the vlan that the port is a member of.
The link state of the vlan device may need to track only the state of
the subset of ports that are also members of the corresponding vlan,
rather than that of all ports.
Add a flag to specify a vlan bridge binding mode, by which the link
state is no longer automatically transferred from the lower device,
but is instead determined by the bridge ports that are members of the
vlan.
----
Julien Fortin [Wed, 25 Nov 2020 01:09:15 +0000 (02:09 +0100)]
nlcache: master_slaves data-structure should use lists instead of sets
nlcache used a set to keep a master's slave list. This wasn't the right
choice as sets can't guarantee ordering. We need to keep an ordered list
of ports.
Andy Roulin [Tue, 1 Dec 2020 20:45:22 +0000 (20:45 +0000)]
dhclient: wait to start dhcp if carrier is down
This prevents DHCP requests failures taking time during
boot if the interface isn't up yet. If the interface is
down, dhclient will fail to send packets.
At boot-time, enslaving an interface to vrf flaps it. By
waiting for the interface to come back up before starting
dhclient reduces time to boot.
addons: bridge: add support for "bridge_always_up_dummy_brport" policy
User may want to have persistent name of dummy port if
"bridge-always-up" option is enabled.
Now the name can be defined in "bridge_always_up_dummy_brport" policy
for bridge module.
Signed-off-by: Alexander Petrovskiy <alexpe@nvidia.com>
Markus Hauschild [Thu, 19 Nov 2020 08:15:15 +0000 (09:15 +0100)]
addons: batman_adv: drop unnecessary exception clause
The exception could have never come from read_file_oneline, also value
was an undefined variable, so it would have thrown an exception while
handling an exception thus being useless anyway.
Signed-off-by: Markus Hauschild <markus@moepman.eu>
Julien Fortin [Fri, 26 Jun 2020 12:49:24 +0000 (14:49 +0200)]
nlcache: link_del: move log.info after get_ifindex check
if the link doesn't exists get_ifindex will raise an exception
new code in the bridge module simply call link_del on a dummy port
that may not exists. It was a bit confusing to see the log.info
stating that a port was getting removed...
addons: vxlan: add vxlan-mcastgrp support for single-vxlan device
this patch adds support for the vxlan-mcastgrp attribute on single
vxlan device. Prior to this commit the vxlan-mcastgrp was only
applied to regular vxlans.