Bug 922702 - [bridge] wrong default for STP
Summary: [bridge] wrong default for STP
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-18 10:25 UTC by Alon Bar-Lev
Modified: 2015-02-23 11:36 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-10 01:26:35 UTC


Attachments (Terms of Use)

Description Alon Bar-Lev 2013-03-18 10:25:53 UTC
Using:
NetworkManager-0.9.8.0-1

Summary:
The default so far was a bridge with STP on (month or so).
Now the default is STP on.

Expected:
Default STP of bridge interface should be off.

Workaround:
Add STP="off" to ifcfg file.

Details:
At the old network service when STP was not specified at ifcfg file of type bridge, the brctl stp was not called, and the system got the default kernel STP value which is off.

Currently, for some reason, NetworkManager overrides this default to on.

This breaks applications such as vdsm, libvirt that assume that default is STP off.

Please respect the old defaults of ifcfg files when adding new functionality to NetworkManager.

Thank you.

Comment 1 Dan Williams 2013-03-21 19:49:35 UTC
Looking into this, it does appear that the initscripts and the kernel default STP to off for both bridge master creation and when the ifcfg does not contain an "STP" property.  We do strive to match the defaults of the old initscripts.

The original bridge patchset from 2012 also appears to default STP to on, and that was carried through to the final NM 0.9.8 release with bridging support.  So there's clearly a discrepancy.

I'm asking around to get a better idea of what the default should be.

Comment 2 Dan Williams 2013-03-22 19:49:56 UTC
NetworkManager's ifcfg-rh configuration plugin was incorrectly interpreting a missing STP setting in the ifcfg file as "on", and that's certainly a bug.  That's now been fixed upstream by:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=360a02fc13635f3d1ff44129ca9d5a8cf7cea2b9

This commit will only turn STP on when an explicit STP=on or STP=yes setting exists in the ifcfg file; otherwise it is off.

(note that, after discussing with the team, we've decided to continue default STP to on when creating new connections through NetworkManager or nm-conection-editor, to ensure that users do not inadvertently bring down a network by creating a bridge loop.  We feel that's a more severe consequence than requiring users or clients that create connections to turn STP off.  This default does not affect tools that write out ifcfg files directly.)

Comment 3 Alon Bar-Lev 2013-03-22 20:04:15 UTC
Thank you.

Although I can argue with your decision of default STP on which is unexpected default compared to all current solutions. The obvious immediate consequence is that most enterprises switches are configured to automatically isolate any edge port to which a switch is connected, this is detected using STP. So adding local bridge for virtualization or VPN results in banning host form network.

These days, most uses of bridge is not the traditional shared media unicast isolation, but the creation of networks within a host. This is why the default of kernel is setting makes sense.

Comment 4 Dan Williams 2013-03-22 22:16:23 UTC
(In reply to comment #3)
> Thank you.
> 
> Although I can argue with your decision of default STP on which is
> unexpected default compared to all current solutions. The obvious immediate
> consequence is that most enterprises switches are configured to
> automatically isolate any edge port to which a switch is connected, this is
> detected using STP. So adding local bridge for virtualization or VPN results
> in banning host form network.
> 
> These days, most uses of bridge is not the traditional shared media unicast
> isolation, but the creation of networks within a host. This is why the
> default of kernel is setting makes sense.

I do see your point; I'm CC-ing Thomas Graf here to see if he has any additional thoughts on this.

Comment 5 Fedora Update System 2013-03-28 01:21:49 UTC
network-manager-applet-0.9.8.1-1.git20130327.fc18,NetworkManager-0.9.8.1-1.git20130327.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/network-manager-applet-0.9.8.1-1.git20130327.fc18,NetworkManager-0.9.8.1-1.git20130327.fc18

Comment 6 Fedora Update System 2013-03-29 01:32:55 UTC
Package network-manager-applet-0.9.8.1-1.git20130327.fc18, NetworkManager-0.9.8.1-1.git20130327.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing network-manager-applet-0.9.8.1-1.git20130327.fc18 NetworkManager-0.9.8.1-1.git20130327.fc18'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-4549/network-manager-applet-0.9.8.1-1.git20130327.fc18,NetworkManager-0.9.8.1-1.git20130327.fc18
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2013-04-10 01:26:38 UTC
network-manager-applet-0.9.8.1-1.git20130327.fc18, NetworkManager-0.9.8.1-1.git20130327.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.