Ticket: CM-8729
Reviewed By: Nikhil
Testing Done: Tested with vlan device with vlan-raw-device in interfaces
file
also reported here: https://github.com/CumulusNetworks/ifupdown2/issues/10
is_keyword was matching iface attribute 'vlan-raw-device' to the vlan
keyword and dropping it from ifaceobj config.
Ticket: CM-9595
Reviewed By:
Testing Done: tested with failing vrf config in CM-9595
due to same upperiface getting processed more than once,
there was an unnecessary refcount inc on the lowerdevice.
This patch aborts processing upperiface if already
processed and also adds a new debug function to
dump lower and uppper ifaces of all interfaces in the
file.
The vrf device may not be up when ifup is executed on the
slaves. This commit makes sure:
- vrf slaves dont try to enslave themselves when vrf device is
not present
- And vrf master enslaves any missing slaves during ifup of vrf master
- Also make vrf device the link master, this will make sure
the vrf device brings the vrf slave links up. This is needed to work
around the ipv6 address flush issue
Closes: CM-9493
Review: dsa, nikhil, wkok (via git send-mail)
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds a new upperiface module handler get_upper_ifacenames
to get upperifaces from a addon module. This is called during building
dependency graph.
Closes: CM-9493
Review: dsa, nikhil, wkok (via git send-email)
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-8455
Review: CCR-4181
Testing: tested ifreload on builtin interface change
This patch handles removal of builtin interfaces (example swp*.100
below..which dont have iface sections) during a ifreload.
{noformat}
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports swp3.100 swp15.100
{noformat}
if user changes swp15.100 to another interface and does a ifreload,
before this patch swp15.100 used to be around. This patch makes sure
swp15.100 is deleted in the process
I had to do some cleanup of flags in the process. I might have added
some extra cycles to ifreload. But i dont see an easy way to handle this
case.
Ticket: CM-9078
Reviewed By: CCR-4110
Testing Done: clag bond add/del and clag slave add/del
This change basically does the following -
1. Proto-down swpX pre-clag-bond-enslave
2. Proto-up swpX post-clag-bond-release
Setting/clearing of clag-id will result in similar proto-state changes
and those are handled by clagd.
Note:
I really wanted to keep these changes out of ifupdown2 but the
order of setting is critical i.e. protodown has to happen enslave to
prevent additional flaps/STP TCNs. Theoretically #2 can be done by clagd
but there is no easy way to do #1.
Ticket: None
Reviewed By: CCR-4058
Testing Done: ifup'd interface with both dhcp-wait: "no" and dhcp-wait: "yes"
and not specified at all.
A previous patch implemented the nowait option for DHCP. This patch changes the
name of the option to "dhcp-wait" and makes the default, if nothing is specified
in the policy files, to be "yes", which means dhclient will be called without
the "-nw" option, causing it to wait for up to a minute for a response from the
DHCP server before continuing.
The format of the JSON in the policy file for this option was also changed so
that it conforms to the other ifupdown2 policy options. This format is now:
{
"dhcp": {
"defaults": { "dhcp-wait": "no" }
}
}
Also, the documented argument values are "yes" and "no". Any other values, will
be interpreted as "yes".
A subsequent patch in cl-basefiles will be made to include this fragment in
/var/lib/ifupdown2/policy.d/dhcp.json so that Cumulus Linux will default to
not waiting for DHCP to complete.
Change policy manager default policy file location:
from /var/lib/ifupdownaddons/policy.d to
/var/lib/ifupdown2/policy.d
This aligns well with the user policy file location:
/etc/network/ifupdown2/policy.d/
Fixes 59dad2ca80("debian: sync debian files with from upstream debian repo")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
before this commit, an error in reading a sourced file would
result in an error. This commit converts it to a warning and continue
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Add back missing ifupdown/ifupdownconfig.py.
fixes a cherry-pick error.
Fixes 0582f185ed ("ifupdown2: address: squash addr config and process
them on the youngest sibling")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-8330
Reviewed By: balki
Testing Done: Tested with interfaces file in the bug
(cherry picked from commit 14570e6d442d1c9a3742f1dd989f7af673e3cc7f)
Ticket: CM-7995
Reviewed By: CCR-3850
Testing Done: Tested exit code on syntax errors
This patch adds members 'errors' and 'warns' to networkinterfaces.py
to track errors and warns during parsing interfaces file.
This patch also adds --syntax-check option to ifreload
given people seem to use ifreload more than ifup these days.
$ ifreload --syntax-check -a
error: /etc/network/interfaces: iface swp1.200: unsupported keyword (roopa-attr)
$ echo $?
1
(cherry picked from commit e643a136fcf5d387ff0f9a31cb6a6af4983e1012)
Ticket:
Reviewed By:
Testing Done: Tested ifquery --check with bridge-pvid
bridge-pvid and bridge-vids on a bridge does
not correspond directly to a running config
on the bridge. They correspond to default
values for the bridge ports. And they are
already checked against running config of the
bridge port and reported against a bridge port.
So, This patch ignores these attributes under the bridge.
Uses '2' for ignore today. XXX: '2' will be
mapped to a defined value in subsequent patches.
Before:
auto bridge
iface bridge
[fail]
bridge-vlan-aware yes [pass]
bridge-ports swp3 swp4 [pass]
bridge-pvid notfound [fail]
After:
auto bridge
iface bridge
[pass]
bridge-vlan-aware yes [pass]
bridge-ports swp3 swp4 [pass]
bridge-pvid 20
(cherry picked from commit 29e70abbf7920cf94c3ebd738dd757c2ca27b35c)
Ticket: CM-7917
Reviewed By: CCR-3845
Testing Done: Tested changing address and ifreloading on multiple iface stanzas
In presence of multiple iface stanzas, current ifupdown2 does not purge
existing addresses.
Because each ifaceobject processing looks at only its stanzas and it is
afraid that it may purge running addresses that does not belong to
itself. Historically multiple iface stanzas are processed individually
than squashing them as a single interface. Squashing iface stanzas into
a single iface stanza has been a problem in the past and also does not
work well with iface stanzas that are supported by ifupdown (I dont have
a specific problem example right now...but)
This patch processes all address attributes when processing the first iface
object (or iface stanza). Unsure if this can be a surprise to existing
users. It should not but cant say sometimes people have weird things in
their pre-up/post-up commands. Hence this is controlled by a ifupdown2.conf
variable addr_config_squash=0 set to off by default. still debating if this
can be on by default.
When addr_config_squash=0 and existing addresses are not purged a
warning is displayed:
"warning: swp1: interface has multiple iface stanzas skip purging
existing addresses"
(cherry picked from commit 7aaa75674547392f2abb8273b18671f0795b3eaf)
listed interface that had a blacklisted parent
Ticket: CM-7851
Reviewed By: CCR-3664
Testing Done: Tested with auto/non-auto dependent and non-dependent interfaces
example config from sam:
iface swp3.100
auto swp3
iface swp3
iface swp3
address 66.66.66.66/24
Ticket: CM-6740
Reviewed By: roopa
Testing Done: tested multiple ifreloads with various test cases
In the case of duplicate iface stanzas where one of the stanzas sets
the link attributes, ifupdown2 was confused because the absence
of link attributes forced it to reset them to default values
(when they existed).
This patch tracks link changes and prevents resetting to defaults
only if there are no explicit settings configured. Furthermore,
only the last interface processed (from the duplicates) will take
care of resetting to defaults.
Ticket: CM-7851
Reviewed By: CCR-3639
Testing Done: Tested a combination of auto and non-auto interfaces.
This fixes a regression introduced in 2.5.4 where ifreload was
picking up non-auto interfaces
This also fixes a minor issue with blacklisting interfaces introduced by
("450c679249b546dbc2cd97d81b49e011fec948bd remove blacklisted interfaces
only if they are upperifaces (ie root of the tree") when an interface
has multiple auto and non-auto stanzas (A rare case, but it was an easy
fix and around the same area).
example, the fix will now blacklist an interface only if all of its stanzas are
blacklisted. In the below example, swp4 is not blacklisted if user
specified auto because one of the iface stanzas is auto.
auto swp4
iface swp4
iface swp4
address 10.0.14.2/24
(cherry picked from commit ad6d4567fdf9413c804a348c1712d8706934264a)
Ticket: CM-7066
Reviewed By: roopa
Testing Done: unit tested and wrote new testcase in testifupdown2
Use case for ifquery where stdin used with -i breaks
because interfacesfileiobuf was not checked in addition to interfacesfilename.
Testcase like:
echo '[{"name": "swp1","auto": true,"config": {"address": "10.10.10.10/24"}}]' | ifquery -i - -t json swp1
would fail because while -i was given with stdin, the check for missing filename would produce an error.
It was also decided by consensus that the ifquery command does not need to have a check for
disable_cli_interfacesfile since a query "should" not pose a security check.
(I've also added some test cases for this in cl-tests).
(cherry picked from commit 4d37e932b43da87a9240a866be2d8b9508a9c7eb)
the tree)
Ticket: CM-7765
Reviewed By: CCR-3621
Testing Done: tested interface dependencies with auto and non-auto
interfaces
This commit fixes a change in behaviour introduced by "460906d0552d" ("skip adding
filtered or blacklisted interfaces in the dependency graph") that
skipped non-auto (or blacklisted) interfaces.
Turns out we have files out there that do have non-auto
dependents. This patch makes sure blacklisted interfaces who are
dependents of other interfaces are always picked up.
to make sure the state file in persistent storage is cleaned up
correctly
Ticket: CM-7774
Reviewed By: CCR-3623
Testing Done: Tested statefile accross reboots
ifupdown2 state file was moved to /var/tmp because /var/tmp was tmpfs
and was large enough (100MB) for the state file. But it appears it has
changed (or is not consistent) across all platforms. We can move it
under /run, but /run again size varies on various platforms and it is
too small on some platforms.
This patch:
- continues to keep the ifupdown2 state file under /var/tmp (because it
needs the space)
- ntroduces a second level /run/network/ifstatelock file that stays on
non-persistant storage and is used to delete the state file at /boot up
Ticket: CM-7635
Reviewed By: CCR-3575
Testing Done: Tested failing ifquery output in json format
This patch fixes a bug introduced by 0dea0cfeeec8b342ee2e2b767daa4071ac760f31
("Add support to display status (pass, fail) in ifquery --check json
output").
This patch separates the json encoders for iface objects with and
without status (ifaceJsonEncoder and ifaceJsonEncoderWithStatus) so
that they dont interfere with each other.
Ticket: CM-7464
Reviewed By: CCR-3507
Testing Done: Tested ifquery check sanity
ifquery --check non-json output displays 'pass' and 'fail' for
each attribute on the same line (see below). This output is not json
friendly. For json, include status in 'config_status' a dictionary
whose keys are similar to the 'config' dictionary but values are status
for the corresponding keys in the 'config' dictionary (see example below)
auto bond4
iface bond4 inet static
[pass]
bond-mode 802.3ad [pass]
bond-miimon 100 [pass]
bond-use-carrier 1 [pass]
bond-lacp-rate 1 [pass]
bond-min-links 1 [pass]
bond-xmit-hash-policy layer3+4 [pass]
bond-slaves swp3 swp4 [pass]
[
{
"name": "bond4",
"addr_method": "static",
"addr_family": "inet",
"auto": true,
"config": {
"bond-use-carrier": "1",
"bond-miimon": "100",
"bond-lacp-rate": "1",
"bond-min-links": "1",
"bond-slaves": "swp3 swp4",
"bond-mode": "802.3ad",
"bond-xmit-hash-policy": "layer3+4"
},
"config_status": {
"bond-use-carrier": "pass",
"bond-miimon": "pass",
"bond-lacp-rate": "pass",
"bond-min-links": "pass",
"bond-slaves": "pass",
"bond-mode": "pass",
"bond-xmit-hash-policy": "pass"
},
"status": "pass"
}
]
Ticket: CM-7066
Reviewed By: scotte,roopa,olson
Testing Done: Unit testing and regression testing
This patch does two things:
1. It moves the interfaces config file name to the ifupdown2.conf file in /etc/network/ifupdown2.
This should allow administrators to specify a config file location different from the default and allow
subsets of users to use it without giving them access to specifying their own with the -i option in ifup/ifdown.
2. It also adds a new config setting called "disable_cli_interfacesfile" used to prevent users
from specifying their own interfaces file. This defaults to "1" (even if it is not configured).
Note: this new default takes away users ability to specify an interfaces file.
This should close the vulnerability where users could specify their own interfaces file
and add arbitrary user commands.
This leaves the shell=True option in the user commands add-on module since the ifup/ifdown/ifreload/ifquery
commands already require root access to run and the interfaces config file also requires root access to modify.
Ticket: CM-6702
Reviewed By: roopa
Testing Done: unit and smoke tested with ifupdown2 suite
When address-virtual mac adddress is modified, removed from an SVI, or the SVI is removed,
the permanent mac address is not removed.
This patch addresses all three cases but creating a global statemanager instance
and removing address-virtual FDB entries that were previously configured.
Ticket: CM-6619
Reviewed By: CCR-3191
Testing Done: Tested upperiface bringup for bridge and vlan devices
'up' on bridge was always done to add the newly created port to the bridge
in cases where the bridge is not part of the interfaces being brought
up. But This will try to re-apply bridge port attributes on all bridge
ports and that can take a while when there are large number of bridge
ports. This patch currently avoids the bridge up for only the vlan
aware bridge case.
Ticket: CM-5882
Reviewed By: gospo
Testing Done: unit tested
When a user enters an interface name longer than 15 characters,
the error message is not clear about what the problem is.
warning: netlink: Numerical result out of range <<<<<<<<<<<<<<<<
This patch catches the error before netlink gets the call and
prints
error: the following interface names are too long: bond-xconnect.1006
Ticket: CM-6525
Reviewed By: trivial
Testing Done: Tested with failing config mentioned in the bug
c4d27f53e965af5edc938acae25bcb249a2214a7 introduced a
new interface kind of BRIDGE_VLAN_AWARE which broke the
scheduler check. This patch fixes the check.
Ticket: CM-6106
Reviewed By: roopa,scotte
Testing Done: ran ifupdown2 regression suite and hand tested
This patch prevents IP address assignment under vlan aware bridges.
This prevents some confusion because a bridge subinterface is required
for layer 3 termination.
Ticket:
Reviewed By: CCR-3043
Testing Done:
This was resulting in lower interfaces not being brought up at boot
when their upper-ifaces were not-marked auto. And this was because
the dependency graph continued to have the non-auto upper interfaces
and the whole tree was ignored by the scheduler.
This fix eliminates filtered interfaces from the dependency graph
to simplify the scheduler and also to avoid scheduler picking up
non-auto (or non-class interfaces).
testcase (Without this patch swp1 was skipped at boot)
iface swp1.100
auto swp1
iface swp1
Ticket: CM-5146
Reviewed By: roopa,jtoppins
Testing Done: built new ifupdown package and ran testifupdown2 suite of tests
This patch prevents enslaved interfaces from having IP addresses.
(cherry picked from commit 0c00606fbc76db11557a8e946310e93a2b376aa7)
(cherry picked from commit dc30987acfc6af356b9e055db95d94ae45f0de9f)
Ticket: CM-5254
Reviewed By: roopa
Testing Done: tested master and 2.5_br images with testifupdown2 suite and hand tested
This patch creates a json defaults file upon bootup
(which can be overridden by customer configs in /etc)
which the ethtool module in ifupdown2 will consult
when "link-x" configs are removed in order to restore
them to the initial settings used by the switch.
(cherry picked from commit 8388664f5a5a85f2a813cafbf40ac92d7b86f4bf)
Conflicts:
packages/cl-utilities/usrlib/update-ports
(cherry picked from commit 21c9c10ab2fccaf60be9accb337e82541d497cc4)
sections for that interface changed
Ticket: CM-5841
Reviewed By:
Testing Done: tested ifreload with new iface section
<email_notes>
problem stmt:
if the user adds a new section for an existing interface, I mark the
interface for down.
Basically the below:
if len(newifaceobjlist) != len(lastifaceobjlist):
ifacedownlist.append(ifname)
continue
You rarely need to add a new section to the interfaces file. It is not
recommended even by the user guide.
sankaran was trying to add a new address. Which he could have added to
the same iface section.
But, looking at his trivial example, i am thinking of not marking an
interface for down if the user merely tried to add a new section to an
existing interface
</email_notes>
ifdown behaviour.
Ticket: CM-5819
Reviewed By: CCR-2846
Testing Done: tested ifreload evo test case
ifreload_down_changed is 0 by default which will make
sure ifreload will not execute down on changed interfaces
but only on deleted interfaces making it non-disruptive.
some notes from CCR:
ifreload was designed to be an optimization for 'service networking
restart' or 'ifdown -a + ifup -a'.
essentially it is a combination of 'ifdown + ifup' with some smarts in
which interfaces it will execute ifdown on.
By default it does the below:
ifdown all interfaces that were deleted from the interfaces file
ifdown all interfaces that were changed from the last time they were
ifup'ed
ifup -a (execute ifup on all interfaces marked auto)
Did not realize people will use ifreload as much as they do today. Also,
they may execute it on a production box when changes are made. ifdown on a production box can be
disruptive because if the ifdown which is part of the ifreload.
To have a non-disruptive option to ifreload, 2.5 added a new option -c
that only executed 'ifup' on all interfaces. Thus reloading all auto +
any other interfaces that were once brought up on the box (essentially
all interfaces present in the saved state file). This by default did not
do anything to the interfaces that got deleted from the file. But had an
ifupdown2.conf toggle to do so.
Looking at the evo use case, they do want to use a single command that
modifies, adds, deletes with
minimum disruption. we can achieve maybe what they want with multiple
commands (But there is also a case of a bug in the build evo is running
which makes it not so easy ).
This patch fixes the bug and also tries to change the default ifreload
behaviour controllable via a variable in ifupdown2.conf.
when ifreload_down_changed=0 in ifupdown2.conf, ifreload will only
ifdown interfaces that were deleted
from the file but not the ones that changed. subsequent ifup as part of
ifreload on the interfaces
that changed will apply the delta. And ifreload_down_changed default
value is '0'.
WIth the patch, ifreload by default will do the below (going back to the
previous default is just a toggle in the ifupdown.conf file):
ifdown all interfaces that were deleted from the interfaces file
ifup -a (execute ifup on all interfaces marked auto)
It sounds like a big change of behaviour for a hotfix release, but
essentially the patch just moves a few things around. And the change in
behaviour is so subtle that it is not very visible.
It just makes it non-disruptive.
(cherry picked from commit 2f7977834d4912a69159d27e54ba201f58a321d8)
Ticket: CM-5693
Reviewed By: roopa
Testing Done: tested bridge and bonds with interfaces with configs
Both bridge and mstpctl modules set priv_flags on interfaces
that have configs (like link-speed) even when used as bridge-ports.
And this collision causes statemanager.ifaceobj_sync() to never get called
because ifaceobj.priv_flags is 1 (we return immediately):
The fix was to create a new iface module_flags array to carry module info.
Ticket: CM-5571
Reviewed By:
Testing Done: tested ifreload with example in the bug
ifdown of the bridge svi was following the lowerdev and downing the
bridge. kernel implicitly deletes all svi's on bridge down.
ifup of the bridge usually handles it, but a change done in 2.5.1
was causing it not to. Thinking about this some more, its safe
to not follow dependents on down during a ifreload. This patch does
just that.
Ticket: CM-5349
Reviewed By: Trivial
Testing Done: Tested on cel box
Corrected a minor error in how we handle unsupported config attributes.
Instead of
error: not enough arguments for format string
we will now print this:
warning: peerlink.4000: unsupported attribute 'clagd-foobar'
(cherry picked from commit 44c6004a33d59ee234f8ee3d5f450e158c9e5bdc)
way)
Ticket:
Reviewed By: trivial
Testing Done: Tested interface upperiface bring up
This was causing the auto upperiface bringup to pick all upperifaces on
malliks setup. This is a large number in a 500 svi setup.
Ticket: CM-4417
Reviewed By: roopa
Testing Done: Build powerpc image and tested alternate json format
ifupdown2 was patched to handle nonlist JSON input since this
is a valid format.
(cherry picked from commit 2597194f6f34344495f3a2b44bfe1d05887e1e77)
