Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1342557

Summary:	[RFE] Implement and/or configure forward_bpdu on bridges on hypervisors to allow STP-enabled switches to detect and prevent network loops
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Tim Speetjens <tspeetje>
Component:	RFEs	Assignee:	Rob Young <royoung>
Status:	CLOSED WONTFIX	QA Contact:	Raz Tamir <ratamir>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.6.1	CC:	danken, edwardh, lsurette, pablo.iranzo, srevivo, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	lsvaty: testing_plan_complete-
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-10-13 12:07:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1195208
Bug Blocks:

Description Tim Speetjens 2016-06-03 14:02:35 UTC

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.

Comment 3 Dan Kenigsberg 2016-06-19 15:25:46 UTC

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.

Comment 5 Tim Speetjens 2016-07-04 11:49:39 UTC

Implementation using OVS is sufficient, imho.

Tim

Comment 10 Edward Haas 2018-07-23 16:52:11 UTC

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.

Comment 11 Dan Kenigsberg 2018-10-13 12:07:13 UTC

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.