Bug 922702

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.

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.)

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.

(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.

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

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).

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.