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>
The previous implementation failed to properly convert
mac address with missing leading-zeros.
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>
This patch will detect interfaces that were removed from /etc/network/interfaces
but still got pick up by a regex (i.e. bridge-port vni*) and manually remove
those interfaces from internal data-structures (i.e. dependency graph).
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>
