While doing some other research recently, I ran across the Bridge Assurance feature in Cisco gear, which was new to me. Cisco has been working on ways to avoid STP melt-down and Bridge Assurance is another tool to help network administrators keep networks running.
STP problems occur when forwarding loops are inadvertently created. Loops are caused by several problems:
- Unidirectional link
- Device malfunction
- Configuration error
- External system forwarding (hub or non-STP switch or dual-NIC server bridging between NICs)
The functions that Cisco has added to the switch product line to provide network administrators greater control over interfaces that should be forwarding frames between network equipment and interfaces that should connect to edge devices. A quick summary of the features:
- UDLD – Uni-Directional Link Detection puts unidirectional links into blocking state and prevents forwarding loops.
- BPDU Guard – disables ports that receive a BPDU frame; useful for edge ports that should never be connected to another switch.
- Loop Guard – Protects against ports where the link becomes unidirectional. It operates differently than the UDLD function.
- Root Guard – Prevents a port from becoming a root port or a blocked port.
- EtherChannel Guard – Prevents inconsistent configuration of EtherChannel that creates loops between two switches.
- Bridge Priority – Defines the root bridge in an STP domain.
A description of these features, and the Bridge Assurance feature are documented at:
Configuring Optional STP Features (Catalyst 6500 Release 12.2SXH and Later Software Configuration Guide)
Bridge Assurance only runs in RSTP or MST networks. It makes sure that a neighboring switch does not malfunction and begin forwarding frames when it shouldn’t. It does this by monitoring receipt of BPDUs on point-to-point links. When the BPDUs stop being received, the port is put into blocking state (actually a port inconsistent state, which stops forwarding). When BPDUs restart, the port resumes normal RSTP or MST modes. This handles unidirectional links as well as the malfunction of a neighboring switch where STP stops sending BPDUs but the switch continues to forward frames.
Looking at the features, I realized that we have a set of tools that allow us to control spanning tree topology. In any network design, certain ports are to be edge ports and other ports are to be infrastructure (switch-to-switch) ports. The features for controlling STP operation would be applied to either edge ports or infrastructure ports as desired. Port-specific configuration has been around a whle in the metro Ethernet product line, where the ports have defined types. For example, the Cisco ME3400 switch port definitions are either Network to Network Interface (NNI, set with the command “port-type nni”) to connect to other network gear or a User to Network Interface (UNI, the default) to connect to edge devices.
By careful design and selection of primary and backup paths, we can design STP networks with known failure modes and pre-defined traffic patterns when failures occur. Taking advantage of these features means that we should spend more time designing STP networks, with the advantage that we spend less time troubleshooting failures and the networks are more reliable. My point is that we should take the time to create the desired STP topology instead of quickly interconnecting a bunch of switches and relying on STP to create the loop free topology.
-Terry
_____________________________________________________________________________________________
I’ve written about spanning tree in prior posts:
_____________________________________________________________________________________________
Re-posted with Permission
NetCraftsmen would like to acknowledge Infoblox for their permission to re-post this article which originally appeared in the Applied Infrastructure blog under http://www.infoblox.com/en/communities/blogs.html
that is just amazing .. many thanks bro
you helped me better understand Bridge Assurance 😀
Keep the hard work
Best of Luck
I think a couple of points can be added to this article:
1) I would point out that BPDU’s usually aren’t transmitted from Alternate Ports (blocked port leading to the root) or from Backup Ports (blocked port connected to an upstream switch) as they are in Discarding/Blocking State, but they do receive BPDU’s.
2) With Bridge Assurance enabled, Alternate and Backup ports continue to send BPDU’s. The key to this not causing problems is that the RSTP/MST BPDU’s include the role and state of the sending port. So the switches on both sides are verifying their port’s role as seen by their neighbors. If their port’s role is not consistent with the neighbor’s port role, then the port goes into inconsistent state/blocking.