Ticket: CM-12988
Reviewed By: julien, nikhil, dsa
Testing Done: tested ifup and ifdown of vrf devices with address virtual
slaves
This patch fixes up macvlan device enslavements when vrf device
or vrf slave is brought down and up. address virtual macvlan
devices on vrf slaves need to enslaved to the vrf. This
patch checks and fixes up those vrf enslavements for the following
cases:
ifdown <vrf_device> && ifup <vrf_device>
ifdown <vrf_slave> && ifup <vrf_slave>
starting state:
------------
$ip -br link show
myvrf UP 46:c6:44:db:37:60 <NOARP,MASTER,UP,LOWER_UP>
bridge.901@bridge UP 44:38:39:00:77:88 <UP,BROADCAST,MULTICAST,UP>
bridge-901-v0@bridge.901 UP 00:00:5e:00:01:81 <UP,BROADCAST,MULTICAST,UP>
$ifdown myvrf
$ip -br link show
bridge.901@bridge DOWN 44:38:39:00:77:88 <BROADCAST,MULTICAST>
bridge-901-v0@bridge.901 DOWN 00:00:5e:00:01:81 <BROADCAST,MULTICAST,M-DOWN>
before patch (macvlan device bridge-901-v0 did not come up:
----------------------------------------
$ifup myvrf
$ip -br link show
bridge.901@bridge UP 44:38:39:00:77:88 <UP,BROADCAST,MULTICAST,UP>
bridge-901-v0@bridge.901 DOWN 00:00:5e:00:01:81 <BROADCAST,MULTICAST>
myvrf UP ce:a6:e1:85:75:73 <NOARP,MASTER,UP,LOWER_UP>
after patch:
------------
$ifup myvrf
$ip -br link show
bridge.901@bridge UP 44:38:39:00:77:88 <UP,BROADCAST,MULTICAST,UP>
bridge-901-v0@bridge.901 UP 00:00:5e:00:01:81 <UP,BROADCAST,MULTICAST,UP>
myvrf UP ce:a6:e1:85:75:73 <NOARP,MASTER,UP,LOWER_UP>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-11214
Reviewed By: Roopa
Testing Done:
Previously we were adjusting the macvlan mtu based on the wrong device.
We used to do, using the config example bellow:
get_mtu(ifaceobj.lowerifaces[0])
get_mtu("bridge")
instead of doing get_mtu(bridge.20)
$ cat /etc/network/interfaces
auto tap0
iface tap0
#mtu 9000
mtu 1500
auto bridge
iface bridge
bridge-ports tap0
auto bridge.20
iface bridge.20
address 10.7.192.194/27
address-virtual 44:38:39:ff:00:20 10.7.192.193
$ ifreload -a
$ ip link show
bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
bridge.20@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
bridge-20-v0@bridge.20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
$ #change mtu to 9000
$ ifreload -a
$ ip link show
bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default
bridge.20@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default
bridge-20-v0@bridge.20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: None
Reviewed By: Daniel Walton
Testing Done:
This commit was need to keep nclu and ifupdown2 consistent.
The naming were differing and we decided to keep nclu version.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-8101
Reviewed By: CCR-4949
Testing Done: smoke tests + ran ifup -a -s on every interface configuration file from GSS cl-supports collection
This commit is introducing ~20 keywords. The value of the different attributes
will be check against raw values and <keywords>:
'<mac>'
'<text>'
'<ipv4>'
'<ipv6>'
'<auto>': "auto"
'<ipaddr>': ipv4/6 with preflix len
'<number>'
'<interface>'
'<ipv4-vrf-text>': equivalent to: <ipv4> "vrf" <text>
'<number-ipv4-list>': example: "100=172.16.100.1 101=172.16.101.1"
'<interface-list>': example: "swp1 swp2 swp3"
'<ipv4/prefixlen>'
'<ipv6/prefixlen>'
'<ipaddr/prefixlen>'
'<number-range-list>': example: "2000 2200-3000"
'<interface-range-list>': example: "swp1=100 swp2=100" ('validrange' : ['0', '65535'])
'<mac-ipaddr/prefixlen-list>'
'<number-interface-list>': example: "4 swp1 swp2"
'<interface-yes-no-list>': example: "swp1=yes swp2=no"
'<interface-yes-no-0-1-list>'
'<interface-yes-no-auto-list>'
It's possible to combine a keyword with a range from validrange. example:
validrange: 10-50
validvals: <intrface-range-list>
value: swp1=21 swp2=42 ...
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-11803
Reviewed By: dsa, scotte, wkok, nikhil, julien
Testing Done: tested config of address-virtual lines on vrf slaves
This patch does the following:
- addressvirtual: enslaves macvlans created on vrf slaves
to the vrf master
- vrf: when looking for stale slaves on vrf master, skip
macvlan devices. This code does basic checking right now
and can be improved to include more cases.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-11745
Reviewed By: Roopa, Nikhil G
Testing Done: configuration provided in the bug
User was attempting to configure a traditional bridge under a VRF with VRR.
When issuing ifreload -a, the configuration failed to apply with an error.
Applying an address-virtual keyword to an interface with upper interfaces
or parent interfaces was not allowed. But now we are allowing the use of
this keyword only for vrf slaves.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-11511
Reviewed By: CCR-4890
Testing Done: Used "address-virtual" keyword to create VRR interface with IPv6
address. Checked sysctl and dad failures.
In a VRR setup, both switches are programmed with the same IPv6 address and that
address is active on both switches. This causes the IPv6 duplicate address
detection to kick in and diable the use of one of the address on one of the
switches. This patch causes duplicate address detection to be disabled on VRR
interfaces by setting the net.ipv6.conf.<ifname>.accept_dad and
net.ipv6.conf.<ifname>.dad_transmits sysctl's to 0. The only IPv6 addresses
which are defined on these interfaces are the virtual addresses and the link
local address (which is unused). No other operational IPv6 addresses should ever
be assigned to these interfaces. Instead, operational IPv6 addresses should be
assigned to the "base", or lower, interface of the VRR interface.
Ticket: CM-8736
Reviewed By: Roopa
Testing Done: Smoke tests + the ones from the ticket
By default ifupdown2 will adjust logical devices MTU
based on the physical interface they are running on top of.
set this flag to 0 to disable this behaviour
adjust_logical_dev_mtu=1
Ticket: cleanup
Reviewed By:
Testing Done: Tested ifupdown sanity
This gets rid of some ugly previous flag handling which was
passed through modules. This creates a global instance of
flags that all addon modules and helper modules can use.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This reverts commit 934c4c49c0.
Ticket: CM-10175
Reviewed By: Roopa Prabhu
Testing Done: yes, by installing ifupdown .deb file onto dell-s3000-02
default addr fix for vrf check is deleting lo addrs accidentally
info: rtnetlink: setting link lo up
info: executing ip addr del ::1/128 dev lo
info: executing ip addr del 127.0.0.1/8 dev lo
info: eth0: running ops ...
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-8658
Reviewed By: Roopa Prabhu, Scott Emery
Testing Done: Yes, by installing ifupdown .deb file onto cel-e1031-01
This patch includes a check for multicast bit of vrr virtual mac
address and set an error
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-8143
Reviewed By: scotte, roopa
Testing Done: ssim and powerpc
This was first seen as a side issue with switchd terminating and not restarting (filed as CM-8109).
When ifreload -a is issued, all of the vrr interfaces were bounced, even though there were not any
configuration changes.
In keeping with the philosphy of making ifreload non-disruptive, this patch no longer
disrupts vrrs if the existing config has not changed.
Ticket: CM-6702
Reviewed By: roopa
Testing Done: unit and smoke tested with ifupdown2 suite
When address-virtual mac adddress is modified, removed from an SVI, or the SVI is removed,
the permanent mac address is not removed.
This patch addresses all three cases but creating a global statemanager instance
and removing address-virtual FDB entries that were previously configured.
Ticket: CM-4639
Reviewed By:
Testing Done: Tested with interfaces file and steps from the bug
This is a Hack to make sure the primary address
is the first in the routing table. Its not a full proof solution.
We use `ip route get` on the vrr network to see which
device the kernel returns. if it is the mac vlan device,
flap the macvlan device to adjust the routing table entry.
flapping the macvlan device makes sure the macvlan
connected route goes through delete + add, hence adjusting
the order in the routing table.
Ticket: CM-4178
Reviewed By:
Testing Done: Tested vrr interface up and down
Checking and deleting is expensive. so, ignore delete failures.
Currently logs them at debug level.
Ticket: CM-3346
Reviewed By:
Testing Done: Tested new format with new bridge driver
- add/del vlan aware bridge svi mac addresses from bridge
- shorten macvlan interface names to <bridge>-<vid>-v<n>
- fix query check for address-virtual interfaces
- fix query check for vlan interfaces
