addons: address: add dad handling module global

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.

nlcache: add nodad parameter to addr_add

nlpacket: change IFA_FLAGS to a FourByte attribute

AttributeGeneric cannot be used unless having it's length defined.

This change allow address flags such as optimistic, nodad or others
to be set with the add_attribute packet method.

Merge pull request #231 from CumulusNetworks/revert-230-dad_handling

Revert "Dad handling"

Revert "Dad handling"

Merge pull request #230 from sohorx/dad_handling

addons: address: add support for DAD

addons: address: update modinfo for dad attributes

Help infos came from the ifupdown (original) manual.

addons: address: up: wait on dad when needed

addons: address: add a settle dad method

_settle_dad will allow ifupdown2 to wait on ipv6 dad tentative.

addons: address: disable dad on no attempts

networkinterfaces: dad attrs placement behavior

Fix the dad-attempts and dad-interval placement behavior to be linked
against it's related address.

addons: address: get new dad attributes

dad-attempts and dad-interval can now be taken from the interfaces
file.

Those attributes names came from ifupdown (original).

nlcache: add nodad parameter to addr_add

nlpacket: change IFA_FLAGS to a FourByte attribute

AttributeGeneric cannot be used unless having it's length defined.

This change allow address flags such as optimistic, nodad or others
to be set with the add_attribute packet method.

Merge pull request #228 from dverbroekkenexnl/patch-1

Update iface.py : Corrected a typo when the interface is set to KEEP_LINK_DOWN

Update iface.py

Corrected a typo then the interface is set to KEEP_LINK_DOWN

addons: vlan: retry vlan creation if bridge_binding capability is missing

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>

Merge pull request #220 from Manawyrm/wait-for-udev

debian: Run ifupdown2 after udev has settled

Merge pull request #219 from Carbenium/source-directory

networkinterfaces: support source-directory statement

implement code review

networkinterfaces: support relative paths in source/source-directory statements

According to interfaces(5) [1]:
When sourcing files or directories, if a path doesn't have a leading slash, it's considered relative to the directory containing the file in which the keyword is placed. In the example above, if the file is located at /etc/network/interfaces, paths to the included files are understood to be under /etc/network.

Adapt the implementation to adhere to the documented behaviour.

[1] https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html

networkinterfaces: support source-directory statement

ifupdown supports the "source-directory" statement that include the content of the specified directory.
See [1] for details.
Implement the statement to improve compatibility with ifupdown.

Fixes #191

[1] https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html

Merge pull request #225 from devicenull/master

Sort filenames in interfaces.d so they're parsed in a consistent order

Sort filenames in interface.d so they're parsed in a consistent order

Merge pull request #224 from polz113/polz113-xmit-hash-policy-vlan-srcmac

Update bond.py - add xmit-hash-policy vlan+srcmac

Add support for xmit-hash-policy vlan+srcmac

Add support for xmit-hash-policy 5 - vlan+srcmac, added in Linux 5.12.

Merge pull request #223 from kvadrage/tunnel_tos_ttl_fix

addons: tunnel: add tunnel-tos attribute and "inherit" support

addons: tunnel: new attribute: tunnel-tos

'tunnel-tos': {
    'help': 'TOS for tunnel packets (range 0..255), 1=inherit',
    "validrange": ["0", "255"],
    'validvals': ['<number>', 'inherit'],
    'required': False,
    'example': ['tunnel-tos inherit'],
    "aliases": ["tos"]
}

Signed-off-by: Alexander Petrovskiy <alexpe@nvidia.com>

addons: tunnel: add 'inherit' value to 'tunnel-ttl' attribute

Signed-off-by: Alexander Petrovskiy <alexpe@nvidia.com>

Merge pull request #170 from Jasperswaagman/master

Add none as valid value for bridge-ports on a bridge interface

Merge pull request #221 from li-kunkun/fix-default-route-add

Fix adding a static IPv6 default route failed on RA networks

Fix adding a static IPv6 default route failed on RA networks

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>

debian: Run ifupdown2 after udev has settled

addons: vxlan: fix lib.addon.Vxlan import (fixes: #217)

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

nlcache: fix TypeError: argument of type 'IPNetwork' is not iterable

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: introduces old_ifaceobjs to get_dependent_ifacenames

Other addon modules need to access the list of old ifaceobjs

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

usercmd: fix TypeError: unsupported operand type(s) for |: '_Environ' and 'dict'

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

debian: changelog: new 3.1.0-1 entry

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

nlcache: clean duplicated code (link_add)

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

nlcache: update link_set_bridge_info_data_dry_run

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

cleanups - upstream sync

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

nlcache: addr_add: convert pointtopoint and broadcast attribute to ipaddress obj

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>

lib: nlcache: new netlink API "link_add" (waits for link creation)

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: link: ifquery-check now validates admin state

[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>

nlcache: link_set_address: override cache after mac address change is aacked

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>

iproute2: svd: convert vnifilter attr to boolean to cover all case

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: ifquery-check: mcastgrp-map: use bridge vni show

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: remove stale code (bridge fdb show call)

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: fix name 'vni_mcastgrp_map' is not defined

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: mcastgrp-map: remove validval attribute

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: refactoring code to allow updating an existing SVD

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: fix mcast group get api during vni filter set

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>

addons: vxlan: remoteip-map: check user config against old config and not running state

'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>

addons: vxlan: ifquery-check: don't check fdb running state if mcastgrp-map or remoteip map are not configured

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>

addons: vxlan: allow svd config update

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: add null list check when mcastgrp map not present

Signed-off-by: Roopa Prabhu <roopa@nvidia.com>

addons: vxlan: support for vxlan-support-mix-dev-types policy (default yes)

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: error out when an unsupported mix of SVD and TVDs are configured

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>

lib: iproute2: fix missing bridge_vni_del function

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

lib: iproute2: batch vni filter commands

Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: use new vni filter api to set mcast groups per vni

Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

ifupdown2: lib: dont bring down link during vni filter changes

Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: add 'Exception' to try/catch

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge-vlan-vni-map: add vlan reserved check

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: add more details log error when finding duplicated vnis

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: fix consecutive vni ids mapped to incorrect range vids

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: add batching commands for vids add/del

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: fix bridge-vlan-vni-map range processing

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: fix delta calculation between old and new config

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: remove stale entry from running config

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: don't add old_ifaceobjs to internal MVAB list

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

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.

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

lib: iproute2: add vxlan bridge default fdb entries with state permanent

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>

lib: iproute2: use self flag when adding svd fdb entries

Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

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.

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: add support for new attribute: vxlan-remoteip-map

syntax:
vxlan-remoteip-map 1000-1005=10.0.0.1,10.0.0.42-10.0.0.45,10.0.0.90-10.0.0.95
vxlan-remoteip-map vni-range=ip-range,comma-separated

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: process mcast groups after the addition of vnifilter

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>

bridge: support values of auto, auto+, auto- for vni in bridge-vlan-vni-map

<vlan>=<vni>
<vlan>=auto  /* sets vni = vlan */
<vlan>=auto+2 /* sets vni = vlan+2 */
<vlan>=auto-2 /* sets vni = vlan-2 */

example:
$ifquery vxlan1
auto vxlan1
iface vxlan1
        vxlan-local-tunnelip 27.0.0.30
        bridge-vlan-vni-map 1000-1009=auto+2 2000-2020=auto-2
        mstpctl-portbpdufilter yes
        mstpctl-bpduguard yes

$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

Reviewed by: slaffer, david marshal, qzil, julien
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: ifquery-check support for vxlan-mcastgrp-map

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

vxlan: fix ttl for single vxlan device

Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

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.

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>

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

Reviewed-by: Julien Fortin <jfortin@nvidia.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: improve mcastgrp-map handling of fdb entries

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: add support for vxlan-mcastgrp-map with ipmr-lo dummy physdev

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: vxlan: single-device: update log.warning when device already exists

updating an existing singe-vxlan-device is not supported yet, we should warn
the user accordingly.

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: use vlan and vni ranges within iproute2 cmds

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>

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).

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: fix display error vnis=vlans instead of vlans=vnis

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: ifquery-running support for bridge-vlan-vni-map

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge-vlan-vni-map: support multiple vni mapping per entry

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-vlan-vni-map: fix: not enough arguments for format string

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: check if bridge mac is already inherited from a port

Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: bridge-arp-nd-suppress should show up on ifquery --with-default if policy is set

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

clag: bridge l3vni: move bridge vxlan l3vni code to parent class + refactoring

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

bridge.py: remove extra empty line in header

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: fix bridge arp vni vlan syntax-check

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: v2: arp suppression enabled when no vlan is configured

the previous patch didn't cover implicit vlan, format bridge.VLANID

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: skip bridge arp vni vlan for single vxlan device

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: detect and warn when arp suppression is enabled and there is no vlan configured

Signed-off-by: Julien Fortin <jfortin@nvidia.com>

addons: bridge: detect VXLAN mis-config VNI "bridge-learning=on" and print log message

Signed-off-by: Julien Fortin <jfortin@nvidia.com>