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)
Ticket: CM-4462
Reviewed By:
Testing Done: Tested with interfaces file given in the bug.
The 'network down' msg from the kernel is when the lower device is not
'admin up'. In CM-4462 it is seen when the vlan interface on the bond
is 'admin up' when the bond is still in 'admin down' state.
The bond is also a bridge port so, bond will be 'admin up' when
the bridge it belongs to is brought up.
As link_master_slave feature is on only when all network interfaces
are brought up/down, the states of all interfaces will eventually
converge to 'admin up', so ignoring such transient 'network down' messages.
link master slave feature when '-a' is not specified.
Ticket: CM-4408
Reviewed By:
Testing Done: Tested with ifupdown2.conf link_master_slave on/off
This will make the behaviour change mostly invisible to users
Conflicts:
packages/ifupdown2/ifupdown/ifupdownmain.py
in vlan module to use rtnetlink api
Ticket: CM-4173
Reviewed By:
Testing Done: Tested new bridge driver svi up/down
This does not move all 'bridge vlan' commands to rtnetlink yet.
Ticket: CM-3346
Reviewed By:
Testing Done: Tested ifupdown2 sanity
- moved 'admin up' delays that we introduced recently to be
configurable via two ifupdown2.conf attributes
# Let link master (bridges, bonds) own the link state of slaves
link_master_slave=1
# Delay admin state change till the end
delay_admin_state_change=0
- reduced some redundant traversal of dependency trees
- fixed a few bugs in query check
issues with having it in flags) + add check for bond slave being already up
Ticket: CM-4408
Reviewed By:
Testing Done: some bond sanity test
(cherry picked from commit 346b62a41fbf4521008cd8a9b0fa227e75a5d994)
sure that slaves can never be brought admin up on their own when they
are not in the bond
Ticket: CM-4408
Reviewed By: CCR-2323
Testing Done: Tested ifup/ifdown of bond slaves and bond interface
This patch introduces:
- introduces 2 interface flags, LINK_MASTER and LINK_SLAVE.
- The bond module will set LINK_MASTER on the bond iface object
indicating that the bond module owns the link.
- Which means that all lower devices /slaves of the bond get their
link when the bond (aka LINK_MASTER) is processed in the bond module
- The module that queries dependencies propagates the LINK_SLAVE flags
on the dependents of LINK_MASTER.
- The scheduler now acts on the LINK_SLAVE flag. If LINK_SLAVE is set,
it skips setting admin 'up' on that interface. It also makes sure the
interface is not already in the bond.
ie if an interface is a LINK_SLAVE (bond slave in this case), admin
up will not be executed when the interface is not inside the bond.
(cherry picked from commit 84b5a07a4f7685c7ae2eac5892889d6c0e08b2eb)
sure that slaves can never be brought admin up on their own when they
are not in the bond
Ticket: CM-4408
Reviewed By: CCR-2323
Testing Done: Tested ifup/ifdown of bond slaves and bond interface
This patch introduces:
- introduces 2 interface flags, LINK_MASTER and LINK_SLAVE.
- The bond module will set LINK_MASTER on the bond iface object
indicating that the bond module owns the link.
- Which means that all lower devices /slaves of the bond get their
link when the bond (aka LINK_MASTER) is processed in the bond module
- The module that queries dependencies propagates the LINK_SLAVE flags
on the dependents of LINK_MASTER.
- The scheduler now acts on the LINK_SLAVE flag. If LINK_SLAVE is set,
it skips setting admin 'up' on that interface. It also makes sure the
interface is not already in the bond.
ie if an interface is a LINK_SLAVE (bond slave in this case), admin
up will not be executed when the interface is not inside the bond.
Ticket: CM-4336
Reviewed By:
Testing Done: Tested with the missing port testcase from CM-4336
(cherry picked from commit 82a976ada6ba208bde089805d613413a5b016f8d)
variable names) + also fix a condition that looks incorrect
Ticket:
Reviewed By: wkok
Testing Done: Tested with the failing
This was seen in a case where mako is unable to render the template
or incorrectly renders it due to user template
errors, leaving interface names with
mako variables in them. There is no easy way to
recognize and warn about these. This patch tries to warn the user
of such cases by looking for variable patterns ('$') in interface names.
(cherry picked from commit fc0d45a794a61f7e6a3fd2c2ebce3d621bf0c7b2)
variable names) + also fix a condition that looks incorrect
Ticket:
Reviewed By: wkok
Testing Done: Tested with the failing
This was seen in a case where mako is unable to render the template
or incorrectly renders it due to user template
errors, leaving interface names with
mako variables in them. There is no easy way to
recognize and warn about these. This patch tries to warn the user
of such cases by looking for variable patterns ('$') in interface names.
over ifup handling of upperifaces by default) + some fixes in the
reserved vlan check
Ticket: CM-3346
Reviewed By:
Testing Done: Tested ifupdown sanity.
Ticket: CM-4204
Reviewed By:
Testing Done: Tested ifreload with interfaces file in the bug
My last checkin moved the auto flag around causing the breakage
