Ticket: CM-13817
Reviewed By: Roopa, Kanna, Nikhil G
Testing Done:
1) use inet and inet6 dhcp in interfaces file
2) do a ifup -v
3) make sure dhclient v4 and v6 is running
4) now remove inet6 dhcp section
5) ifreload -a -v (should kill dhclient6)
6) replace inet by inet6
7) ifreload -a -v (should kill dhclient4 and exec dhclient6)
etc.. I played with all possible combinations
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13737
Reviewed By: Roopa, Nikhil G
Testing Done:
Incremental commit for CM-13737
Create a policy file such as:
$ cat /var/lib/ifupdown2/policy.d/defaults_policy.json
{
"README": "This file is automatically generated. Do not edit this file.",
"ethtool": {
"defaults": {
"link-autoneg": "off",
"link-duplex": "full",
"link-speed": "1000"
},
"iface_defaults": {}
}
}
then do ifdown lo && ifup lo
without this patch or af8734d18a9e173a89db982285e801eb31deab5d
you would reproduce the fail
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
It was initially set in a place where only interfaces with
dependencies were processed. This patch moves it to the right
place.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
auto br0
iface br0
bridge-ports swp1 swp2
bridge-ports swp3 swp4
running ifquery in this configuration gaves us 2 identical warnings:
warning: br0: ignoring duplicate bridge-ports lines: ['swp3 swp4']
warning: br0: ignoring duplicate bridge-ports lines: ['swp3 swp4']
when running ifreload -a we still see 2 warnings, this will need to be looked
at later.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13248
Reviewed By: Roopa, Kanna, Nikhil G
Testing Done: See bug
Today before starting dhclient6, we are sleeping 2 seconds we need to make sure
the configured interface is up and has a link-local address.
In some cases 2 seconds is not enough. This patch will install a retry loop
with a 10 sec timeout.
We are querying ip -6 addr show to make sure the interface is properly confi-
-gured but in the future the plan is to move this call to netlink.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-12988
Reviewed By: julien, nikhil
Testing Done: Tested ifdown and ifup of vrf device with --with-depends
This patch fixes transient errors like below on vrf slaves when
vrf device is being brought up with --with-depends:
"error: swp1: vrf vrf1 not around, skipping vrf config
error: br100: vrf vrf1 not around, skipping vrf config
error: br101: vrf vrf1 not around, skipping vrf config"
In this patch, the vrf device is brought up on bringing
up of the first vrf slave. This is also done in the normal
ifreload -a case.
history on --with-depends for vrf: On vrf device down,
a bunch of slave state gets cleaned up.
and today, ifup of vrf device alone does not fix all that state
especially when there are vrr (macvlan) interfaces involved.
One has to use --with-depends. This is now also part of documentation
https://tickets.cumulusnetworks.com/browse/UD-851
$ifdown vrf1
$ifup vrf1 --with-depends
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
bridge-access is given
Ticket: CM-13683
Reviewed By: julien
Testing Done: Tested with bridge-access, bridge-pvid and bridge-vids on
a bridge-port
$ifquery swp21 bridge
auto swp21
iface swp21
bridge-access 100
bridge-pvid 100
auto bridge
iface bridge
bridge-ports swp20 swp21
bridge-vlan-aware yes
$ifreload -a
warning: swp21: bridge-access given, bridge-vids and bridge-pvid will be
ignored
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-13221
Reviewed By: julien, nikhil
Testing Done: tested mtu propagation for vlan devices
This is a followup to commit
29de36f36053 ("addons: address: various fixes for mtu handling").
This fixes a pending issue with mtu readjustments on vlan
interfaces on top of physical interfaces.
eg: with the below config:
$ifquery -a
auto swp1.100
iface swp1.100
auto swp1
iface swp1
mtu 9000
/* at boot-up swp1 and swp1.100 mtu is set to 9000 */
$ifdown swp1 /* resets swp1 mtu to 1500. swp1.100 mtu is reset to 1500
implicitly by the kernel */
$ifup swp1 /* swp1 mtu is set to 1500. But swp1.100 mtu stays at 1500
*/
This problem is unique to physical interfaces and vlan devices on
physical interfaces. This is because, when logical interface is ifdown,
kernel deletes all its sub-interfaces. And on the way up (ifup),
ifupdown2 re-creates all these sub-interfaces for you....that
sequence re-adjusts the mtu. For physical
interfaces, since the sub-interfaces are not deleted,
ifupdown2 does not do anything...and mtu of the subinterface is left to
what it was. And this ends up being what was there initially when the
lower interface went down. And ifdown of the lower physical interface,
resets the physical mtu to default which is 1500. The sub-interface mtu
returns to 1500 while the lower physical interface remains down.
(another detail here: kernel vlan driver re-adjusts mtu of the vlan
sub-interface on its own when the lower device mtu becomes lower. But
does not re-adjust its mtu when the lower device mtu increases. This is
expected and correct behavior). We will have to work around it in
ifupdown2 to suit our needs.
two solutions:
a) when physical interface is brought up, ifupdown2 can go and
pro-actively adjust the upper sub-interface mtu
OR
b) when physical interface is brought down, do not reset the mtu on the
device to default
(b) is the easiest and costs less if we dont expect the mtu of a
physical device to go to default on ifdown.
(a) is doable too, but is additional cost to go over all upper
interfaces.
This patch fixes this problem with solution (a). But, makes sure
this does not add additional cost to the default ifreload -a path.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: None
Reviewed By: Roopa
Testing Done:
This was discover while working on CM-13767 and some other vxlan issues
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
This reverts commit 32e2363a694e5fdf535e45db7ef6baba8cab2ed4.
I pushed this commit by mistake. It was a local commit waiting to be reviewed.
Reverting it for now, might be applied later after positive review.
Ticket: CM-13536
Reviewed By: None
Testing Done: Sankaran tested it out
The IFLA_ADDRESS and IFLA_BROADCAST attributes for all interfaces has been a
6-byte MAC address. But the GRE interface uses a 4-byte IP address for this
attribute. This patch allows for decoding a 4-byte value as an IP address as
well as a 6-byte value as a MAC address.
Ticket:
Reviewed By: Roopa, Daniel W, Nikhil G, Dave O, Scott E
Testing Done: ifupdown2 smokes
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-12713
Reviewed By: Roopa, Nikhil G
Testing Done: Test from the bug
% for i in range(1,49):
iface swp${i}
mtu 9216
link-speed 10000
link-duplex full
link-autoneg off
% endfor
auto swp1
iface swp1
% ifup -a -v # should only up swp1
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13316
Reviewed By: Roopa, Nikhil G
Testing Done:
auto v0
iface v0
vlan-id 100
vlan-raw-device tap1
auto v1
iface v1
vlan-id 100
vlan-raw-device tap2
auto v2
iface v2
vlan-id 100
vlan-raw-device tap3
auto br0
iface br0
bridge-ports tap9 regex v.*
In this specific case, if you remove v0 then execute ifreload ifupdown2 will
barf and say that v0 still exists as a dependency of br0.
From roopa:
The problem here is that the dependency gathering should have been done after
the ifdown's. However the ifdown's need the dependency tree for built in
interfaces which could be part of globs. And this dependency tree needs to be
the current state of things so can't do the selective picking of interfaces
either. So, its a chicken and egg problem.
Ideally when one uses regex, if he is removing an interface that was matched by
a regex, he has to do a 'ifdown' manually today. 'ifdown v0' in this case.
So today we decided to change the warning message to let the user know that he
should manually down the interface that matches a regex.
This is not a permanent fix but a work-around. We don't want to introduce new
changes that may introduce false positive case for existing and working config
post 3.2:
-----------
we should consider doing the down's in two phases during ifreload
a) down everything that we are very certain was removed from the file
(to make sure regex's don't catch it).
b) build dependency tree and run through the down's once more, to
catch all glob matches for built-in interfaces
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
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>
