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.
fix vxlan-tos inherit = 1 (was set to 0)
and other fixes to make sure we don't unnecessarily set
those attributes on vxlan creation
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
make sure to convert the mtu received via policy file back to string
before using it in the bridge module.
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>
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
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
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
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
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.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.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>
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.
Reviewed-by: CCR-10987
Closes: CM-32460
Co-developed-by: Nilesh Shinde <nilesh@nvidia.com>
Signed-off-by: Andy Roulin <aroulin@nvidia.com>
since we've updated ifupdown2 to pytho3 the error
message should mention python3-mako and not
python-mako (python2)
Ticket: CM-29621
Reviewed By: Roopa
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
In debian 10, ifupdown2 didn't ensure that it will start before network.target and network-online.target.
after local-fs.target because ifupdown2 need to read config file from local filesystem
Other network services will not start after networking.service and fail because no interface is up.
(e.g isc-dhcp-server, tftp-hpa)
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>
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>
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>
