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>
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.
----
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
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.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
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...
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
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.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
force_add_slave was designed to be called right after the link_set_master
call to override our internal cache and not wait for the kernel and register
the slave/master relationship in our internal data-structures. It turns
out the kernel can be faster than us here. So an additional check is needed
to make sure we don't do duplicate operations that would result in the
slave being removed from an internal data-structure.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
original commit ported to the python3 branch:
commit bffa619b11ae7aa9e567c26c255c17ac6df2c495
Author: Maximilian Wilhelm <max@rfc2324.org>
Date: Sat Jan 14 19:08:01 2017 +0100
Add option 'veth-peer-name' to veth links and ensure proper configuration.
The option »veth-peer-name« forces an veth peer link to be created with
a specific interface name. As the interface name of the "local" part of
the veth link pair already is defined by the name of the interface stanza
this option is added to, now both sides are clearly named.
As there is a bidirectional dependency of both link pairs - both cannot
exist without the other - this presents a problem when setting up all
interfaces. Depending on which interface is set up first there might be
a problem when only on dependency is specified. Therefore adding the
»veth-peer-name« option to both interface of the veth link pair ensures
that regardless of which side is configured first the peer name will be
set correctly. This intentionally creates a circular dependency which is
handled accordingly.
Fixing the config check for veth link-type while at it :)
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
