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-12753
Reviewed By: roopa, julien
Testing Done: used same config mentioned in the bug
Changed %d to %s inorder to print a string.
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: None
Reviewed By:
Testing Done:
The function _create_vrf_dev is surrounded by a try/catch as follow:
try:
vrf_table = self._create_vrf_dev(ifaceobj, vrf_table)
except Exception, e:
self.log_error('%s: %s' %(ifaceobj.name, str(e)), ifaceobj)
Thus we shouldn't include the ifaceobj.name in any error message passed to
log_error(). Since this function will raise an exception by default, it will
result in something like this:
error:br0.4002: red: red: create failed (cmd 'ip link add name red type vrf table 1001' failed: returned 1 ...[snip]
error:red: red: create failed (cmd 'ip link add name red type vrf table 1002' failed: returned 1 ...[snip]
after this patch:
error: red: create failed (cmd 'ip link add name red type vrf table 1002' failed: returned 1 ... [snip]
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket:
Reviewed By: Roopa, Nikhil G
Testing Done:
ifupdown2's python addons are replacing some/most of the old ifupdown shell
scripts. When addon_scripts_support is set to 1, ifupdown2 will execute every
scripts present in /etc/network/if-$ACTION.d/ if a script exists with a name
identical to an ifupdown2 addon, this script won't be executed.
Sometimes an ifupdown2 addons doesn't have the same name as the ifupdown script
it's supposed to replace. Or maybe one addon is replacing several scripts.
For example: bond.py is replacing /etc/network/if-*.d/ifenslave
Now each addon is able to provide a list of script to ignore.
[16:54:40] root:ifupdown2 # ifquery bond0
iface bond0
bond-slaves tap0 tap1
[16:54:49] root:ifupdown2 # ifreload -a -d &> /tmp/ifreload.log
[16:54:54] root:ifupdown2 # cat /tmp/ifreload.log | grep ifenslave
debug: tap1: pre-up : running script /etc/network/if-pre-up.d/ifenslave
info: executing /etc/network/if-pre-up.d/ifenslave
debug: tap1: up : running script /etc/network/if-up.d/ifenslave
info: executing /etc/network/if-up.d/ifenslave
debug: lo: pre-up : running script /etc/network/if-pre-up.d/ifenslave
info: executing /etc/network/if-pre-up.d/ifenslave
debug: lo: up : running script /etc/network/if-up.d/ifenslave
info: executing /etc/network/if-up.d/ifenslave
debug: eth0: pre-up : running script /etc/network/if-pre-up.d/ifenslave
info: executing /etc/network/if-pre-up.d/ifenslave
debug: eth0: up : running script /etc/network/if-up.d/ifenslave
info: executing /etc/network/if-up.d/ifenslave
debug: tap0: pre-up : running script /etc/network/if-pre-up.d/ifenslave
info: executing /etc/network/if-pre-up.d/ifenslave
debug: tap0: up : running script /etc/network/if-up.d/ifenslave
info: executing /etc/network/if-up.d/ifenslave
[16:54:55] root:ifupdown2 #
...
apply patch
...
[16:55:16] root:ifupdown2 # ifreload -a -d &> /tmp/ifreload.log
[16:55:18] root:ifupdown2 # cat /tmp/ifreload.log | grep ifenslave
[16:55:19] root:ifupdown2 #
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-12478
Reviewed By: Roopa, Nikhil G
Roopa: "For vlan aware bridge, we don't support the port attributes under the
bridge. It was deliberately done when vlan aware bridge config was introduced
because people wanted to get rid of the legacy under the bridge way of decla-
-ring port attributes. It was supported for a bit for evorack...in limited
form. we should probably just warn the user about this."
auto br100
iface br100
bridge_ports swp3 swp4 swp5
mstpctl-portadminedge swp3=yes swp4=yes swp5=yes
bridge-vlan-aware yes
$ ifreload -a -s
warning: br100: unsupported use of keyword 'mstpctl-portadminedge' when bridge-vlan-aware is on
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-11393
Reviewed By: dsa, julien, nikhil
Testing Done: tested up and down of a vrf interface
$ifdown -v blue
..snip ..
info: executing /usr/lib/vrf/vrf-helper delete blue 1030
info: executing ip link del blue
info: executing /bin/ss -aK "dev == 54"
info: vrf: syncing table map to
/etc/iproute2/rt_tables.d/ifupdown2_vrf_map.conf
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: CM-12798
Reviewed By: Roopa, Nikhil G
Testing Done:
We are seeing some issue when using IP addresses with inner values padded with
zeros. Such as: 2a01:75e0:0000:09b0::1/64
The kernel will process the ip properly but when we query the kernel again (with
iproute2 or netlink) it returns 2a01:75e0:0:09b0::1/64
Since we are doing string comparaison we are seeing failures. We are now
converting all ip address to a standard format using IPNetwork or IPAddress obj
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-12798
Reviewed By: Roopa
Testing Done:
A customer discovered a corner case: the kernel is shrinking/reducing the ip
address fields containing 0s. For example if we configure and address such as
2a01:75e0:0000:09b0::1/64
Then if we query the kernel (using iproute2 or netlink) it will come back as:
2a01:75e0:0:09b0::1/64
Because of this issue we were seeing
root@r4u28:~# ifreload -a
error: bridge.200: cmd 'ip -force -batch - [addr add 10.50.103.193/26 dev bridge.200
addr add 2a01:75e0:0000:09b1::1/64 dev bridge.200
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
)
Before adding an address to an iface we query it to know if the change is
necessary, since we only do a string comparaison between:
2a01:75e0:0000:09b1::1/64 and 2a01:75e0:0:09b1::1/64
it fails, ifupdown2 thinks that a change is needed. So we try to add the new
address via iproute2. iproute2 will fail because this address in a "shrinked"
format already exists.
This patch hot-fixes this problem by ignoring the error if it's an "exists"
error, we don't want to confuse the user.
A later fix will the real issue by normalizing all ip addr to the IPNetwork
format.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-12049
Reviewed By: dsa, julien, nikhil
Testing Done: tested with and without /etc/iproute2/rt_tables.d/
OS does not have /etc/iproute2/rt_tables.d, on errors just info:
$ifreload -a -v
info: unable to save iproute2 vrf to table map ([Errno 2] No such file
or directory: '/etc/iproute2/rt_tables.d/ifupdown2_vrf_map.conf')
info: cannot find /etc/iproute2/rt_tables.d. pls check if your iproute2
version supports rt_tables.d
OS has /etc/iproute2/rt_tables.d, on errors warn:
$ifreload -a
warn: unable to save iproute2 vrf to table map ([Errno 2] No such file
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12494
Reviewed By: roopa, julien
Testing Done: used config mentioned in bug
'ifquery -r' on a specific bridge port was not removing
pvid from the list of vids.
This patch does that.
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-12552
Reviewed By: julien, nikhil
Testing Done: tested with failing config with bridge-access 1
This is similar to the fix done in the below commit for pvid:
"5061730ea5bf ("addons: bridge: fix default pvid handling in cases where
cache is stale")"
easier steps to reproduce:
- have a vlan aware bridge with more than one ports
- add 'bridge-access 1' to one of the ports
- boot the box with the config
- check that the vlans are fine
- ifdown <interface_with_bridge_access_1>
- ifreload -a
- the interface with bridge_access 1 does
not have the pvid flag on vlan 1
This patch makes sure we assume the right running
vid and pvid value ie [1] and 1 if the
cache returns no values. vid = [1] and pvid = 1
are the kernel default/initial values for a port.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12084
Reviewed By: julien, nikhil
Testing Done: tested with --allow=mgmt class
This fixes a problem where vrf map file was getting deleted
at boot during the second invocation of ifup. This is because
the code uses PERFMODE to check it is boot..but does
not realize that this may not be the first invocation of
ifup during the boot.
This patch adds additional checks for mgmt netdev to
make sure we delete the vrf map file only the first time.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
pvid_to_del is calculated
Ticket: CM-12355
Reviewed By: julien, nikhil
Testing Done: tested with failing config
My previous fix for the same bug did not fix the problem completly.
In this patch all running pvid calculation
is done before the pvid_to_del is calculated.
This makes sure the old pvid is deleted if it is not
the same as current pvid in all cases
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12355
Reviewed By: julien, nikhil
Testing Done: tested with failing config
This can happen if the bridge vlans were
cached before the interface become a bridge port.
and when the interface becomes a bridge port
kernel adds a default pvid of 1. so this patch
assumes a default pvid is 1 if we did not find
anything in the cache. This will delete
the default pvid of 1 if the user has configured a
different pvid.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
we should leave the mtu on lo to the default mtu
if user has not requested to change it. lo has
a larger mtu because it does not really depend on a
physical mtu.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12084
Reviewed By: julien, nikhil
Testing Done: Tested ifreload/ifup/ifdown --allow=<class>
vrf slave brings up the master if master is not up yet.
Today this is done only when ALL (auto) option is set
just as an optimization. because you dont want to bring
up the master in cases where user just wants to
bring up the vrf slave. eg ifup -v eth0.
This does not work so well, when user uses
--allow classes to bring up vrf master and slaves
together (eg mgmt vrf).
This patch removes the ALL check when bringing
up master and replaces it with an ALL or
CLASS check. ie make sure vrf master belongs to the
same class as you when CLASS is specified.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-11804
Reviewed By: julien, nikhil
Testing Done: Tested with failing config in the bug
This patch makes sure macvlan devices are ignored by ifquery -ra
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12552
Reviewed By: julien, nikhil
Testing Done: tested with failing config with bridge-access 1
This is similar to the fix done in the below commit for pvid:
"5061730ea5bf ("addons: bridge: fix default pvid handling in cases where
cache is stale")"
easier steps to reproduce:
- have a vlan aware bridge with more than one ports
- add 'bridge-access 1' to one of the ports
- boot the box with the config
- check that the vlans are fine
- ifdown <interface_with_bridge_access_1>
- ifreload -a
- the interface with bridge_access 1 does
not have the pvid flag on vlan 1
This patch makes sure we assume the right running
vid and pvid value ie [1] and 1 if the
cache returns no values. vid = [1] and pvid = 1
are the kernel default/initial values for a port.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12084
Reviewed By: julien, nikhil
Testing Done: tested with --allow=mgmt class
This fixes a problem where vrf map file was getting deleted
at boot during the second invocation of ifup. This is because
the code uses PERFMODE to check it is boot..but does
not realize that this may not be the first invocation of
ifup during the boot.
This patch adds additional checks for mgmt netdev to
make sure we delete the vrf map file only the first time.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
pvid_to_del is calculated
Ticket: CM-12355
Reviewed By: julien, nikhil
Testing Done: tested with failing config
My previous fix for the same bug did not fix the problem completly.
In this patch all running pvid calculation
is done before the pvid_to_del is calculated.
This makes sure the old pvid is deleted if it is not
the same as current pvid in all cases
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12355
Reviewed By: julien, nikhil
Testing Done: tested with failing config
This can happen if the bridge vlans were
cached before the interface become a bridge port.
and when the interface becomes a bridge port
kernel adds a default pvid of 1. so this patch
assumes a default pvid is 1 if we did not find
anything in the cache. This will delete
the default pvid of 1 if the user has configured a
different pvid.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-8610
Reviewed By: Roopa, Nikhil G
Testing Done:
It used to be a silent exception, but not anymore because we catch it and log
accordingly (error) and flag the ifaceobj so that ifupdown2 returns 1.
$ cat /etc/network/interfaces
auto tap0
iface tap0
mtu 9000
address 172.17.28.0/31
$ ifreload -a
$ echo "address 2002:17:27:17/120" >> /etc/network/interfaces
$ ifreload -a
$ echo $?
0
$ # applying this patch
$ ifreload -a
error: tap0: cmd 'ip -force -batch - [addr add 172.17.28.0/31 dev tap0
addr add 2002:17:27:17/120 dev tap0
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
Error: an inet prefix is expected rather than "2002:17:27:17/120".
)
$ echo $?
1
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-8610
Reviewed By: Roopa, Nikhil G
Testing Done:
It used to be a silent exception, but not anymore because we catch it and log
accordingly (error) and flag the ifaceobj so that ifupdown2 returns 1.
$ cat /etc/network/interfaces
auto tap0
iface tap0
mtu 9000
address 172.17.28.0/31
$ ifreload -a
$ echo "address 2002:17:27:17/120" >> /etc/network/interfaces
$ ifreload -a
$ echo $?
0
$ # applying this patch
$ ifreload -a
error: tap0: cmd 'ip -force -batch - [addr add 172.17.28.0/31 dev tap0
addr add 2002:17:27:17/120 dev tap0
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
Error: an inet prefix is expected rather than "2002:17:27:17/120".
)
$ echo $?
1
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
we should leave the mtu on lo to the default mtu
if user has not requested to change it. lo has
a larger mtu because it does not really depend on a
physical mtu.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12084
Reviewed By: julien, nikhil
Testing Done: Tested ifreload/ifup/ifdown --allow=<class>
vrf slave brings up the master if master is not up yet.
Today this is done only when ALL (auto) option is set
just as an optimization. because you dont want to bring
up the master in cases where user just wants to
bring up the vrf slave. eg ifup -v eth0.
This does not work so well, when user uses
--allow classes to bring up vrf master and slaves
together (eg mgmt vrf).
This patch removes the ALL check when bringing
up master and replaces it with an ALL or
CLASS check. ie make sure vrf master belongs to the
same class as you when CLASS is specified.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-11804
Reviewed By: julien, nikhil
Testing Done: Tested with failing config in the bug
This patch makes sure macvlan devices are ignored by ifquery -ra
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
