The default so far was a bridge with STP on (month or so).
Now the default is STP on.
Default STP of bridge interface should be off.
Add STP="off" to ifcfg file.
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.
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:
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.)
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.
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:
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.