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 61c4d7244735 ("Suppress 'Network down' warnings when
link_master_slave feature is on").
The above fix was removed by a recent commit
707aeb737882 ("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>
Ticket: CM-12302
Reviewed By: Daniel, Roopa, Nikhil G
Testing Done: ifupdown2 smoke test
With this pretty straight forward, we introduce a new Attribute in nlmanager,
so that we have single check and no code redundancy for ifname length. This
also prevent loosing time sending a netlink packet for an known error.
Signed-off-by: Julien Fortin <julien@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: None
Reviewed By: Roopa, Nikhil G, Daniel
Testing Done: ifupdown2 smokes
The message logged and the exception raised by nlmanager, when receiving
an NLMSG_ERROR packet from the kernel, wasn't super explicit plus if the
error wasn't a netlink related failure we didn't provide any information
Now we use strerror with the provided error code to generate a nice msg.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: None
Reviewed By: Roopa, Nikhil G, Daniel
Testing Done: ifupdown2 smoke
We used to have these checks in the old rtnetlink python library.
They were missing in python-nlmanager this was a big regression for
ifupdown2.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
statically configured
Ticket: CM-12277
Reviewed By: CCR-5059
Testing Done: ifreload with a VxlanClagClosConfig.py config
get_vxlan_peers gets remote ip addresses if they are statically configured
through ifupdown2 (vxlan-remoteip <address>). These are cached in
ifupdown2's link object so that they can be used in 'ip link set' (if link
exists already), 'ifquery -r' and 'ifquery -c'. ifupdown2 should ignore and
not cache these addresses if they are provisioned by vxrd. Check if vxrd is
running before caching remote ip addresses. This helps in optimizing time
taken to ifreload with 1k bridge/vxlan interfaces (vlan-aware bridge) in a
vxrd/vxsnd setup.
Signed-off-by: Balakrishnan Raman <ramanb@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>
This patch moves ifupdownmain flag IFACE_CLASS to
ifupdownflags.CLASS. ifupdownflags.CLASS is set to true
if the user is asking for a class of interfaces.
example: ifreload --allow=mgmt
By moving it to ifupdownflags, we make it visible
to add modules.
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>
