Ticket: CM-12370
Reviewed By: Roopa, Kanna, Scott E
Testing Done:
This patch also fixes a problem where dhcp6 used to create lease file with
a trailing whitespace. dhcp6 operation were also sometimes using the wrong
pid file. I added some code in the debian.postinst script to correctly
rename these files if they exists when we install/update ifupdown2.
(cumulus-qa-infra/cl-tests/tests/smoke/testdhcp.py:Testdhcp_relay)
auto swp1
iface swp1 inet dhcp
link-speed 10000
link-duplex full
link-autoneg off
auto swp1
iface swp1 inet6 dhcp
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-11536, CM-11537
Reviewed By: julien, nikhil
Testing Done: Tested ifup, ifdown, ifquery for inerface ranges
Code already supports 'iface swp1.[2-4]'
This patch extends that support to include 'iface swp[1-3].100'.
Also fixes boundary conditions described in CM-11537. This
makes it consistent with glob syntax.
example config file with all cases:
auto swp[2-4].100
iface swp[2-4].100
auto swp5.[100-104]
iface swp5.[100-104]
auto br0
iface br0
bridge-ports glob swp[6-7].100
auto bridge.[100-104]
vlan bridge.[100-104]
bridge-igmp-querier-src 123.1.1.1
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports glob swp8-9
bridge-vids 100-104
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-13453
Reviewed By: Roopa, Nikhil G, Daniel W
Testing Done: ifupdown2-tests
We had an issue where python-nlmanager and ifupdown2's nlmanager differed
When netd starts it loads ifupdown2's addons, so it also tries to do the
imports. Since the current working directy is not /usr/share/ifupdown2 but
netd directory it won't load ifupdown2's nlmanager first but python-nlmanager
if it exists.
Here we insert/hardcode /usr/share/ifupdown2/ first in the path to make sure
we load the right nlmanager
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-6908, CM-6110, CM-13221
Reviewed By: julien, nikhil
Testing Done: added a new test in ifupdown2-tests which covers all cases
- move all mtu handling to a single function in addons/address.py
- Have an ifupdown2 default of 1500 mtu
- add a policy manager max_mtu check (we want to default cumulus max mtu
to 9216)
- special handling for bond and bridges
- print an info log abt setting mtu on bridge
- this can be enhanced in the future to look
at individual port mtu and rejecting the bridge mtu.
this operation can be expensive right now. Hence
just an info log.
- bond and vxlan dev mtu follow the rules of physical device mtu
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket:CM-12695
Reviewed By:TBD
Testing Done:
Validated
a) ifup -v <interface>
b) ifdown -v <interface>
c) ifreload -a
Changes:
a) Support for link-fec attribute for link to configure
FEC configuration
Ex:
auto swp17
iface swp17
link-autoneg on
link-fec rs
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Vidya Sagar Ravipati <vidya@cumulusnetworks.com>
Ticket: CM-7361
Reviewed By: CCR-
Testing Done: Tested with clag
Certain loggers, most notably the syslog, don't allow non-printable characters
in their output, and so they convert them to a string of printable characters.
For example, the newline character is converted to #012. This results in output
that looks like this:
2016-08-29T18:50:46.263178+00:00 act-5712-08 clagd[21539]: RXed RTM_NEWNEIGH,
length 68, seq 0, pid 0, flags 0x0#012#012 #033[91mNetlink Header#033[0m#012
1: #033[91m0x44000000#033[0m D... Length 0x00000044 (68)#012 2:
#033[91m0x1c000000#033[0m .... Type 0x001c (28 - RTM_NEWNEIGH), Flags 0x0000
()#012 3: #033[91m0x00000000#033[0m .... Sequence Number 0x00000000 (0)#012
4: #033[91m0x00000000#033[0m .... Process ID 0x00000000 (0)#012
#033[93mService Header#033[0m#012 5: #033[93m0x07000000#033[0m .... Family
0x07 (7)#012 6: #033[93m0x29010000#033[0m )... Interface Index 0x00000129
(297)#012 7: #033[93m0x02000000#033[0m .... State 0x0002 (2), Flags 0x00,
Type 0x0000 (0)#012 Attributes#012 8: #033[92m0x0a000200#033[0m .... Length
0x000a (10) padded to 12, Type 0x0002 (2) NDA_LLADDR#012 9:
#033[92m0x00020000#033[0m .... 00:02:00:00:00:09#012 10:
#033[92m0x00090000#033[0m .... #012 11: #033[94m0x08000900#033[0m ....
Length 0x0008 (8), Type 0x0009 (9) NDA_MASTER#012 12: #033[94m0x2b010000#033[0m
+... 299#012 13: #033[92m0x14000300#033[0m .... Length 0x0014 (20), Type
0x0003 (3) NDA_CACHEINFO#012 14: #033[92m0x00000000#033[0m .... 0#012 15:
#033[92m0x00000000#033[0m .... 0#012 16: #033[92m0x00000000#033[0m ....
0#012 17: #033[92m0x00000000#033[0m .... 0#012#012Attributes Summary#012{'(
2) NDA_LLADDR': '00:02:00:00:00:09',#012 '( 3) NDA_CACHEINFO': (0, 0, 0, 0),#012
'( 9) NDA_MASTER': 299}
which is rather hard to interpret. So this patch modifes the nlpacket debug
output so that the user can specify whether or not color output should be used
by including an extra, optional parameter when instantiating a NetlinkPacket
object. The default is for color output, just like before this patch. But if
color output is not desired, then no VT100 control sequences will be output. Nor
will there be any newline characters embedded in the output.
The NetlinkManagerWithListener and NetlinkManager classes were also modified to
add the same optional use_color attribute, which defaults to True. Thus when
class members which instantiate NetlinkPacket objects are created the
appropriate value for the use_color attribute will be applied.
I also noticed that the default pid_offset of the NetlinkListener class was 2,
when it should have been 1. So I fixed that too.
Ticket: CM-7361
Reviewed By: CCR-5124
Testing Done: Tested with clag
CLAG requires some additional nlmanager functionality. Firstly, different
threads in CLAG with the same PID may instantiate NetlinkManager objects. This
currently assigned each the same pid value, which causes issues. So an optional
pid_offset parameter is added which is added to the PID when instantiating a
NetlinkManager object. This allows multiple threads in the same PID to be able
to have distinct identifiers. If a pid_offset is supplied, it should be 2 or
greater, since 0 and 1 are used by the NetlinkManagerWithListener.
Added two new attribute classes: FourByteList and TwoByteValue. Added an encode
function for the IPAddress attribute, and corrected some length errors in the
MACAddress attribute.
The Neighbor class got actual values for the CacheInfo, VLAN, VNI, IfIndex, and
Master attributes. The "Self" and "Master" flag values were added.
Also added the "family" parameter to the constructor for all attribute classes.
This eliminates the special-casing required for certain attribute's
instantiation.
Ticket: CM-12234
Reviewed By: Roopa, Nikhil G, Daniel
Testing Done:
auto tap0
iface tap0
bridge-access 20
bridge-vids 20
$ ifreload -a -s
warning: tap0: `bridge-access` and `bridge-vids` are not allowed on the same interface
$ echo $?
1
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13086
Reviewed By: roopa, julien
Testing Done: smoke testifupdown2:TestWithdefaults is run
'ifquery -with-defaults' should display default values of
mstpctl-portbpdufilter and mstpctl-bpduguard under bridge port,
but not under the bridge itself
added PORT_PROCESSED flag check to prevent processing
bridge ports again
Example:
auto vxlan1wd
iface vxlan1wd
vxlan-id 1001
auto vxlan2wd
iface vxlan2wd
vxlan-id 1002
auto brwithdef2
iface brwithdef2
bridge_ports vxlan1wd vxlan2wd
bridge-vlan-aware yes
Sample 'ifquery --with-defaults vxlan1wd' output before fix:
auto vxlan1wd
iface vxlan1wd
vxlan-id 1001
Sample 'ifquery --with-defaults vxlan1wd' output after fix:
auto vxlan1wd
iface vxlan1wd
vxlan-id 1001
mstpctl-portbpdufilter yes
mstpctl-bpduguard yes
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
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: None
Reviewed By: Roopa
Testing Done:
This new interface file uses bridge, vlan, vxlan, bond and vrf interfaces.
It's a good way to try ifupdown2 capabilities.
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: 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>
