When an stp is enabled on an existing bridge mstpctl attributes are not always
configured by ifreload. This is due to a timing issue (cache) and some issue in
the mstpctl addon.
- Cache: when changing an existing bridge (done via netlink) we wait for the
kernel ack but we don't update our current cache with the new bridge attributes
This is bad because it means that the bridge cache data are stale until we
receive the notification from the kernel.
- Mstp addon: mstpctl-stp was deprecated in favor of bridge-stp, but in some
place, the mstpctl.py code checks for mstpctl-stp but not for bridge-stp. This
commit fixes the area related to this issue but this should be revisited in
a later commit
Ticket: CM-28951
Reviewed By: Roopa
Testing Done: precommit, smoke, evpn-smoke
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-28312
Testing Done: Test from the ticket
error: link_set_bridge_info_data_dry_run() takes exactly 3 arguments (4 given)
error: link_set_brport_with_info_slave_data_dry_run() got an unexpected keyword argument 'kind'
seems like when updating a method, it's associated dry-run method wasn't
updated accordingly. Maybe there is a way to programmatically check that
I will look into it.
warning: bridge: skipping port X invalid ether addr
warning: interface not recognized - please check interface configuration
Won't show on dry-run anymore
Log info for commands executed with utils.exec_command() weren't prefixed with
DRY-RUN.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
* master:
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
The nlpacket for XFRM had a bug, I also changed iproute2 to add
the XFRM interface to the local cache after creation.
Since XFRM has no IFLA_LINKINFO I made the argument optional.
Otherwise no further operation will be done like adding an IP.
I also removed an unecessary variable in the addon.
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech,de>
The goal of this policy is to ignore ethtool related errors, this is
useful for specific scenario like VMs.
This policy is off by default. To turn it on simply set:
"module_globals" : {
"ethtool_ignore_errors": true
}
under the ethtool top object.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
If we are running in mgmt vrf context and vrf is not specified
on the dhcp interface, use ip vrf exec to start dhclient in the
default context
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Remove/add swp2 from br0 and vrf blue
auto swp2
iface swp2
vrf blue
auto br0
iface br0
bridge-ports swp1
address 10.0.0.11/24
bridge-vlan-aware no
auto blue
iface blue
vrf-table auto
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Currently, the only way to enable arp-accept is to enable
a policy with l3_intf_arp_accept.
But this enable arp-accept for all bridges.
This option allow to define it for specific bridge.
This is needed with bgp-evpn and vm migration
https://github.com/FRRouting/frr/issues/4904
Currently GRO, LRO GSO, TSO, UFO, TX and RX Offload are supported.
One can read the current value with ethtool -k NICNAME.
Values are set with ethtool -K NICNAME gro on lro on gso on tso on ufo on tx on rx on
An example for the config file is:
iface eth0 static
gro-offload no
The default value will be kept in the statemanager. The default value might differ depending on the NIC and is saved upon the first change.
The bridge-ports-condone-regex option can be used to tell ifupdown2 to let
some bridge member ports alone and do not remove them on ifreload runs.
This might come in handy when running a KVM (or any other virtualization
system) host with a bridged network setup.
Before this option, ifupdown2 would either complain about not existing
member ports when setting up the bridge (if all VM interfaces were to
be specified in /etc/network/interfaces) or remove any VM interface
from a bridge if it was not specified in /e/n/i.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Co-authored-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Add a ifupdown2 policy attribute dhcp6-duid to allow user to specify the DUID type
to be used on an IPv6 enabled interface.
Signed-off-by: Rajendra Dendukuri <rajendra.dendukuri@broadcom.com>
Not when we are reloading and applying config ot existing macvlans -
somebody may be using them, we don't want to protodown them in that
case.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
It is available since Kernel 4.19 and has two parmeters:
1. XFRM ID to map to an SA/SAs
2. Underlying Interface if you want to take advantage of IPSec Hardware Offload
Otherwise it is treated as a normal interface and not like a tunnel (VTI).
I added two attributes to the interface to configure it and otherwise use it as a normal interface.
One example is:
auto ipsec1
iface ipsec1 inet
xfrm-physdev lo
xfrmid 1
Add a new attribute for B.A.T.M.A.N. advanced interfaces to control the
B.A.T.M.A.N. advanced routing algorithm to be used when setting up new
interfaces. As the routing algorithm must be set before an interface is
created, it needs special handling and can't be implemented as a common
attribute. D'oh.
Signed-off-by: Maximilian Wilhelm <max@sdn.clinic>
Tested-by: Annika Wickert <aw@awlnx.space>
On ifreload (down ops) we need to purge the cache entry of the bridge and its upper devices
to avoid stale values in our cache.
ifup this config, then remove bridge-vids 20, ifreload: since the bridge is removed because
of ifreload_down_changed=1, we need torecreate the vlan bridge.10 and it's configuration, the
cache is stale. We need to clear it to remove the ip 10.10.10.10/32.
auto bridge
iface bridge
bridge-ports swp1 swp2
bridge-vids 10 20
bridge-vlan-aware yes
auto swp1
iface swp1
link-speed 10000
auto swp2
iface swp2
auto bridge.10
iface bridge.10
address 10.10.10.10/32
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
New VRRP macvlan devices should be set into protodown when first
created, to prevent ND traffic and other automatically generated kernel
traffic from being transmitted on the interface and causing downstream
MAC moves.
Reviewed-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Julien Fortin
Roopa Prabhu
Sven Auhagen
Alexandre Derumier
Rajendra Dendukuri
Maximilian Wilhelm
Quentin Young
Maximilian Wilhelm