Ticket:
Reviewed By: Roopa, Nikhil G
Testing Done:
When using ifupdown2 on regular distribution (debian/ubuntu etc...) users may
not have the latest iproute2/bridge-utils version. Thus the output parsed from
the various subcommands executed by ifupdown2 might defer and cause exception
to be throwned.
We identified several cases:
/sbin/bridge -c -json vlan show
/sbin/brctl showmcqv4src bridge0
/sbin/brctl showstp bridge0
Signed-off-by: Julien Fortin <julien@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:
Reviewed By: Roopa, Nikhil G
Testing Done:
When using ifupdown2 on regular distribution (debian/ubuntu etc...) users may
not have the latest iproute2/bridge-utils version. Thus the output parsed from
the various subcommands executed by ifupdown2 might defer and cause exception
to be throwned.
We identified several cases:
/sbin/bridge -c -json vlan show
/sbin/brctl showmcqv4src bridge0
/sbin/brctl showstp bridge0
Signed-off-by: Julien Fortin <julien@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:
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-12843
Reviewed By: julien, nikhil
Testing Done: Tested the failing test case in the bug
The scheduler already has some checking for errors from
link_up and link_down introduced by
commit 61c4d72447 ("Suppress 'Network down' warnings when
link_master_slave feature is on").
The above fix was removed by a recent commit
707aeb7378 ("netlink ip link set up/down may silently fail, adding
try/except statements"). The scheduler does catch these errors.
so we will need to figure out why the scheduler is not catching it.
Right now this is failing an automation test. So the best fix
is to make sure the previous behaviour is restored.
Signed-off-by: Roopa Prabhu <roopa@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-12596
Reviewed By: Roopa, Daniel W
Testing Done:
before this patch:
$ cat /etc/network/interfaces
auto tapppppppppppp0.42
iface tapppppppppppp0.42
$
$ ifreload -a
warning: /etc/network/interfaces: line8: tapppppppppppp0.42: interface name too long
error: netlink: tapppppppppppp0: cannot create vlan 42: Operation failed with 'None' (RXed NLMSG_ERROR, pid 3346, seq 6, 108 bytes)
$
after:
$ ifreload -a
warning: /etc/network/interfaces: line8: tapppppppppppp0.42: interface name too long
error: netlink: tapppppppppppp0: cannot create vlan 42: Operation failed with 'Numerical result out of range'
$
Signed-off-by: Julien Fortin <julien@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>
Julien Fortin
Nikhil
Roopa Prabhu
Marek Grzybowski
Daniel Walton