Ticket: cleanup
Reviewed By:
Testing Done: Tested ifupdown sanity
This gets rid of some ugly previous flag handling which was
passed through modules. This creates a global instance of
flags that all addon modules and helper modules can use.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-8725
Reviewed By: roopa
Testing Done: tested with user's config on amd64 platform
When setting mstpctl params from user given fdelay and maxage,
ifreload and ifup is setting maxage before fdelay.
Since there is a check for (Bridge Foward Delay - 1 second) >= Bridge Max Age
fdelay must be set before maxage because the fdelay is a default value.
Ticket: CM-7756
Reviewed By: roopa
Testing Done: built powerpc and tested ifupdown2 as well as new tests
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.
(also added test in cl-tests to check this functionality)
(cherry picked from commit 63d0f7082d44fedabe002aebbb658751dc655a46)
Ticket:
Reviewed By: CCR-3804
Testing Done: Tested regex parsing failures
This is mostly a cosmetic fix. we were failing with weird/unclear errors
on unable to parse regex expressions correctly.
This patch mainly adds the interface name to the message and plus adds
an info message showing the actual regex being used in searches.
example config:
{noformat}
auto br-roopa
iface br-roopa
bridge-vlan-aware yes
bridge-ports regex '(\\Aswp3\\Z|\\Aswp4\\Z)'
bridge-pvid 20
{noformat}
before the patch:
warning: br-roopa: error getting dependent interfaces (unbalanced
parenthesis)
after the patch (not pretty but easier to debug)
info: br-roopa: evaluating port expr '['regex', "'(", 'Aswp3', 'Z|',
'Aswp4', "Z)'"]'
warning: br-roopa: error getting dependent interfaces (br-roopa: error
searching regex ''(' in swp38 (unbalanced parenthesis))
(cherry picked from commit bcca6f753a25494666d53f1f2f3c855ffa41d7f0)
This reverts commit bbd11771f5571c67c8f110c2b464817ce31155b9.
This introduced an error where if the config has old bridge driver
and configures port attributes on the bridge, the attributes are reset
to defaults after they are configured by the bridge settings.
(cherry picked from commit 651d1980de02fb108975900ed007087d9a79934c)
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
