Description of problem: As RHEV hypervisors are using bridges for configuring the VM networks, an error in network configuration may lead to a network loop. Though this should never happen, some conditions exist where it has. A network loop has the potential to cause a complete network failure. Therefore, all reasonable measures should be taken to avoid this scenario. STP cannot be activated on the bridges, because this would have consequences for live migration. The next best thing is to allow the network equipment to detect the loop and shut off one or more ports to prevent the loop from taking down the entire network. This is currently impossible because the BPDU packets aren't forwarded between connected interfaces. This RFE requests to make this possible, though this may itself require additional functionality on multiple levels. To make this happen on bridges, the BPDU packets should be forwarded to bridged interfaces. - Linux Bridges The Linux module that implements Linux Bridges was modified to drop these packets, because the standard requires it. This behaviour is not configurable, currently. With regular RHEV networking, this requires a change in the kernel module to allow forwarding of these packets. Using Linux as a virtualization platform is a common use case, which may justify making this behaviour configurable. - Open vSwitch In Open vSwitch this option already exists (forward-bpdu=true) - RHEV When networking is set up, the option should be set for the bridges that support it.
We may be able to set forward-bpdu=true once bug 1195208 allows us to use OVS. To introduce a similar option to Linux bridge, please open a kernel RFE to block this bug.
Implementation using OVS is sufficient, imho. Tim
Forwarding BPDU frames is pretty dangerous, a bridge is not suppose to do so when it acts as a bridge. As the hypervisor bridges are managed by the hypervisors themselves, it would be interesting to understand how such a loop is possible on the hypervisor side. If there is a problem with the host side affecting the overall system stp domain, usually the network admin would just set the physical switches port that connects to the host to "fastforward" or alike and make sure the host bridges have stp disabled. RSTP, if I remember correctly, has a faster recovery time and optimizations and may suffice to enable it even on the hypervisor bridges. With all that said, when OVN takes over an OVS bridge, it usually disables the regular layer-2 (bridging) behaviour mode and starts operating it using specific openflow configuration. In such a case, I do not think a loop is possible and bpdu frames even relevant.
We are unlikely to implement this without a clearer motivation from the customer; however with OvS switchType a customer can modify this manually or via a (yet unsupported yet unwritten) hook.