What is Bridge Assurance?

Author
Terry Slattery
Principal Architect

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:

  1. Unidirectional link
  2. Device malfunction
  3. Configuration error
  4. 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

infoblox-logo

2 responses to “What is Bridge Assurance?

  1. that is just amazing .. many thanks bro
    you helped me better understand Bridge Assurance 😀
    Keep the hard work
    Best of Luck

  2. 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.

Leave a Reply

 

Nick Kelly

Cybersecurity Engineer, Cisco

Nick has over 20 years of experience in Security Operations and Security Sales. He is an avid student of cybersecurity and regularly engages with the Infosec community at events like BSides, RVASec, Derbycon and more. The son of an FBI forensics director, Nick holds a B.S. in Criminal Justice and is one of Cisco’s Fire Jumper Elite members. When he’s not working, he writes cyberpunk and punches aliens on his Playstation.

 

Virgilio “BONG” dela Cruz Jr.

CCDP, CCNA V, CCNP, Cisco IPS Express Security for AM/EE
Field Solutions Architect, Tech Data

Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.

 

John Cavanaugh

CCIE #1066, CCDE #20070002, CCAr
Chief Technology Officer, Practice Lead Security Services, NetCraftsmen

John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services.  Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.

He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.