Ticket: CM-8248
Reviewed By: Trivial
Testing Done: None
Fix for
On bootup and during service network restart these warning messages are thrown out.
root@cel-ken-01:/var/log# service networking restart
[....] Reconfiguring network interfaces...warning: global name 'get_mod_subattr' is not defined
warning: global name 'get_mod_subattr' is not defined
warning: global name 'get_mod_subattr' is not defined
warning messages in ifupdown2
Ticket: CM-7756
Reviewed By: roopa
Testing Done: Tested ssim and powerpc images
Once mstpctl-portbpdufilter or mstpctl-bpduguard is enabled for
an interface, removing the configuration in /etc/network/interfaces
does not toggle the mstpctl state back to no.
The root cause of this problem is that "ifreload" does not check default settings for MSTP configuration
for bridge ports and use a default when that setting is removed from the configuration.
This patch adds a check in the existing loop on attribute values.
If there is no configured value, we check to see if a default exists.
self._modinfo['attrs'][attrname]['default'] exists.
If it exists and it is different then the currently running value
we reset the attribute to its default. This is what a customer would expect if
they removed a configured value.
Ticket: CM-6626
Reviewed By: CCR-3768
Testing Done: Tested with testcase specified in bug
There was an earlier implementation for this for 2.5.4 (CCR-3599 a quick
fix for 2.5.4). This patch re-implements the fix.
This patch essentially handles stp set before and after the port is
processed. It replaces the below commit with the patch in this review
{noformat}
commit 3af351f0a005236e747913bb499c6165e3ec43a4
Author: Roopa Prabhu <roopa@cumulusnetworks.com>
Date: Tue Sep 29 10:12:07 2015 -0700
Fix mstp settings ordering issues when bridge stp is toggled on and
off
(when mstp settings are specified under the port)
Ticket: CM-6626
Reviewed By: CCR-3599
Testing Done: Tested the problem case mentioned in the bug (Plan to
re-work the fix a bit for 2.5.5)
{noformat}
Example:
{noformat}
auto host1
iface host1
mtu 9000
bond-slaves glob swp[25-26]
bond-mode 802.3ad
bond-miimon 100
bond-use-carrier 1
bond-lacp-rate 1
bond-min-links 1
bond-xmit-hash-policy layer3+4
clag-id 1
mstpctl-portadminedge yes
mstpctl-bpduguard yes
auto bridge
iface bridge
mtu 9000
bridge-vlan-aware yes
bridge-ports peerlink host1
bridge-stp on
bridge-vids 1000-3000
bridge-pvid 1
info log stmts:
--------------------
info: host1: ignoring mstpctl-portadminedge config (stp on bridge bridge
is not on yet)
info: host1: ignoring mstpctl-bpduguard config (stp on bridge bridge is
not on yet)
<snip>
info: bridge: processing bridge config for port host1
info: bridge: processing mstp config for port host1
info: executing /sbin/mstpctl showportdetail bridge host1
admin-edge-port
info: executing /sbin/mstpctl setportadminedge bridge host1 yes
info: executing /sbin/mstpctl showportdetail bridge host1
bpdu-guard-port
info: executing /sbin/mstpctl setbpduguard bridge host1 yes
{noformat}
(when mstp settings are specified under the port)
Ticket: CM-6626
Reviewed By: CCR-3599
Testing Done: Tested the problem case mentioned in the bug (Plan to
re-work the fix a bit for 2.5.5)
problem:
mstp parameters can be specified under the port or under the bridge
When they are specified under the bridge, there should be no problem
(When you process the bridge, all things on the bridge port are set in
order)
When they are specified under the port:
we check if the bridge is up, if yes, and stp is already configured,
we process mstpctl settings
This check today only checks running stp_state
We should also check the user configured stp state for the bridge
Note that the problem exists only if the bridge and ports are
already up and user executes ifup again and when we need to re-evaluate
the bridge port settings
solution:
When the bridge port is being checked for mstp settings, not only
check running stp state, but also check user specified stp state and
correct bridge stp state before proceeding with mstp configuration
Few things to note with this patch:
- If user changed stp state on bridge to 'on', and did `ifup
<bridge_port>'`,
though the user has not ifup'ed the bridge yet, the bridge stp state
will be applied (very few people will run into this and practically this
should not be a problem atall. But from correctness POV it is
a voilation. ).
- To avoid this, the other solution would have been to let the bridge
port code be as is, but handle this during bringing up the bridge,
but, this can confuse the user, because when processing the
bridge_port, you will still throw warnings even if the port stp config
is later reapplied when the bridge comes up
- note that the patch only handles the case when stp state is not on and
somebody turned it on. For the case where stp state was on and somebody
turned it off, this patch wont throw warnings for the mstpctl config. But
it will not cause any issues because once stp is off things will be ok
everywhere. I want to keep any changes here out of this patch. I will
document this in the bug...and see if i can handle this in 2.5.5
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-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
