Showing results for 
Search instead for 
Did you mean: 

Nexus 5548 and 6509 VPC Connectivity


We have two 5548 switches connected to a pair of 6509 running in VSS mode. I am trying to understand the benefit of having bridge assurance on the uplink ports.

If we have the command spanning-tree port type network enabled we cannot do a non disruptive upgrade. If there is bridge assurance on the uplink it warns you of this. Yet if I do not run bridge assurance on the uplinks I can do a upgrade without any disruption.

Why in god would I enable bridge assurance on this VPC link if I cannot do a non disruptive upgrade?

Please help me understand


I have attached a diagram showing the connectivity in question

3 Replies 3

Reza Sharifi
Hall of Fame Expert Hall of Fame Expert
Hall of Fame Expert

Do the IOS version on your 6500 support bidge assurance? 

Bridge Assurance

To ensure that the STP can be run on low-end devices, the IEEE standard specifies that "the memory requirements associated with each bridge port are independent of the number of bridges and LANs in the network".  This rule precludes the creation of adjacencies between bridges, as  there can be an arbitrary number of peers connected to a particular  port. On a particular segment, only the designated port ends up sending  periodic BPDUs. Other peers can (and in fact are likely to) remain  silent and no information is collected about them. As a result, there is  no consistency check that can be applied to them either. The typical  dangerous bridging behavior that makes the phrase "STP identify where  not to send frames" (described in "Differences Between Routing and Bridging" section) thus also indirectly stems from that rule.

Bridge assurance is a very simple feature that introduces a counterpart  to portfast configuration. With bridge assurance, a port can be now be  classified in two categories:

Edge ports—ports connected to end stations (existing portfast)

Network ports—ports connected point to point to another bridge

This is not really an additional configuration burden. In order to reach  their full potential, RSTP and MST already required a network with  point-to-point links between bridges, and a strict identification of the  edge ports.

Bridge assurance forces a bridge to keep sending BPDUs on a network  port, even if it is not a designated port. Conversely, a network port  expects receiving periodic BPDUs, even if it is designated. If no BPDU  is received, the port stays in (or reverts to) a discarding state.  Bridge assurance introduce stability in the network by making bridging  closer to routing: a bridge is no longer forwarding traffic by default.  The network port behavior can also be compared to Loopguard without its  plug-and-play aspect. The main weakness of Loopguard was that it was not  started until it had received at least a BPDU and detected a peer.  Bridge assurance does not suffer from this problem as the existence of  the peer is identified by configuration.

Note that this simple consistency check can only be implemented on  point-to-point links because a bridge, contrarily to a router, has no  way of sending traffic to a subset of its neighbors on a shared segment.

As mentioned in "Portfast (Edge Port)" section, the CLI has been enhanced to support bridge assurance:

NX-OS—spanning-tree port type {edge [trunk], network, normal}

IOS—spanning-tree portfast {edge [trunk], network, normal}

The normal setting  allows keeping the current existing spanning tree behavior and will be  necessary on shared segments or port connected to a bridge that does not  support bridge assurance.

The recommended setting for bridge assurance is to consider all ports as  network ports by default, using the following global configuration  command:

NX-OS—spanning-tree port type network default

IOS—spanning-tree portfast network default

This mode will force the network administrator to visit the  configuration of each port and help reveal the most common configuration  errors (like non- identified edge ports, or bridge assurance not  enabled on a neighbor). But most of all, it is safer to have spanning  tree block too many ports than not enough and introduce discarding as  the default port state enhances the overall stability of the network.

More info:


Yes all the switches support bridge assurance

I also found this in the design doc for Nexus switches

The Bridge Assurance feature should not be enabled on the vPC member ports. Bridge Assurance does not add much benefit in a PortChannel-based configuration, and it may intervene in certain vPC failure scenarios in which it is actually less disruptive not to error-disable any port. Also, if you want to take advantage of In Service Software Upgrade (ISSU) on the Cisco Nexus 5000 Series, you should not enable Bridge Assurance on any link except the peer link (referred to as the multichassis EtherChannel trunk [MCT] in the command-line interface [CLI]) on which it is automatically enabled

I really don't think you need bridge assurance. As you have already discovered, it doesn't provide any benefit.  I have never used it.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers