STP on bridge

[tlk_vm]

Hello,

I noticed that with beta2 you enabled STP on the bridges per default. Since 'till now Linux is only capable of doing standard spanning tree, could we please have that as an option to turn off again? Depending on the switch, if they see a legacy STP-BPDU on a port, they fall back to legacy STP entirely, which disrupts traffic flow. Yes, most enterprise switches can do this on a per port basis, but there are some that don't. (NetG... anyone? ;-) )
Also, since we can't tune STP options from the GUI (as of now), our little server might even be elected to be the root bridge, which is not that bad, as long as it keeps running, but once you reboot a new election might be triggered: again: possible network disruption.

Regards,
Marc

 

[dietmar]

I noticed that with beta2 you enabled STP on the bridges per default. Since 'till now Linux is only capable of doing standard spanning tree, could we please have that as an option to turn off again? Depending on the switch, if they see a legacy STP-BPDU on a port, they fall back to legacy STP entirely, which disrupts traffic flow. Yes, most enterprise switches can do this on a per port basis, but there are some that don't. (NetG... anyone? ;-) )

If I understand it STP is needed as soon as you have more than one
Bridge in the network, which is almost always the case. At least
The bidge documentations says so. Why do you think it is not required?


- Dietmar

 

[tlk_vm]

If I understand it STP is needed as soon as you have more than one
Bridge in the network, which is almost always the case. At least
The bidge documentations says so. Why do you think it is not required?

Well, that's not quite true. Then you would need STP always, when you connect two or more switches (which in themselves are a bunch of bridges). But as long as you make sure that you will never form a loop, you do not need STP at all. Say.. you take three switches and connect them in a flat row, so SW1 connects with a single link to SW2 and SW2 connects with a single link to SW3, there is no need for STP. If you now connect SW1 with SW3 (maybe for redundancy), forming a kind of triangle, you have a loop and you must use STP, so that one of the links is pruned/blocked.
If you think of "our" server, which _usually_ only has one physical network card per bridge, there is just no physical possibility to form a loop. Thus no need for STP. And as outlined in my last post, if you enable STP unconditionally it might have a degrading effect on the network, if the STP already in place is not well configured. And _that_ I see much too often.
If there is more than one physical interface in the bridge (without bonding/aggregating) then STP is almost always needed.
Yes, there might be some corner cases where you might need STP even with a single link, but then again: Please, make an option for that.
Oh and please change the default value for the bridge prio to 65k or even better make that a configurable option in the UI so the server almost never is elected to be the root bridge.

Regards,
Marc

 

[dietmar]

Just looked at the xen code. They start the bridge with:

brctl stp ${bridge} off
brctl setfd ${bridge} 0
ip link set ${bridge} arp off
ip link set ${bridge} multicast off

and they add ports with:

ip link set ${dev} arp off
ip link set ${dev} multicast off
ip link set ${dev} addr fe:ff:ff:ff:ff:ff
ip addr flush ${dev}
brctl addif ${bridge} ${dev}

Can somebody explain why they turn off arp and multicast, and assign the mac addr?

- Dietmar

 

[tlk_vm]

Hello Dietmar,

I think that is because the physical interface (eg peth0) is not used anymore for connectivity. Instead the vifs are used. If I understand the docs (and some posts in their mailing list) correctly, they copy the physical MAC to the vif and invalidate the peths with this trick.
I do not see why you should do that in an OpenVZ environment.

Regards,
Marc

 

[dietmar]

If there is more than one physical interface in the bridge (without bonding/aggregating) then STP is almost always needed.
Yes, there might be some corner cases where you might need STP even ...

One off our main design goals is too keep it simple, and one major design prinziple is:

Never ask questions the admin can't answer.

So we need a resonable default value which works everywhere.

Maybe the solution is to use RSTP? Seems there is an userspace implementation somewhere.

- Dietmar

 

[tlk_vm]

Question of philosophy.. I'd say: Someone who adds a bridge with STP enabled to his network and has no idea what that does to his network should not be called admin.
But there is easy logic behind it: One physical interface: no STP. More than one physical interface (not counting bonding): STP enabled.
And to make me happy add an advanced tab with at least STP on/off an bridge prio for every bridge.

(Sidenote: I still have to debug, what it does, when you only add tagged interfaces to the bridge. It should not send STP packets then at all, cause STP is always untagged. (except Cisco's proprietary PVSTP and variants) I will come back to you on that)

Regards,
Marc

 

[dietmar]

But there is easy logic behind it: One physical interface: no STP. More than one physical interface (not counting bonding): STP enabled.

What if you activate more than one bridge, and do arbitrary connections trough them inside VMs (a virtual firewall for example)?

 

[tlk_vm]

then you are either routing inside the VM, so the two host-bridges are not connected and thus no STP needed. Or you are bridging which would connect the host-bridges, but still: inside the VM. So the VM would have to take care of STP or any other means of loop prevention if neccessary, not the host.

Regards,
Marc

 

[dietmar]

Ok, added your suggestion to our todo list.

- Dietmar

 

[thefool808]

One off our main design goals is too keep it simple

I personally think this is fine, since one can easily get into the system and adjust any of the more advanced settings. I don't think it'd be that helpful to spend time adding lots of little switches to the web interface.

Of course, I'm sure no one will stop anybody from adding there own web interface pieces or custom scripts/packages.