Bridge Assurance and Network Ports

Cisco NX-OS contains additional features to promote the stability of the network by protecting STP from bridging loops. Bridge assurance works in conjunction with Rapid-PVST BPDUs, and is enabled globally by default in NX-OS. Bridge assurance causes the switch to send BPDUs on all operational ports that carry a port type setting of “network”, including alternate and backup ports for each hello time period. If a neighbor port stops receiving BPDUs, the port is moved into the blocking state. If the blocked port begins receiving BPDUs again, it is removed from bridge assurance blocking, and goes through normal Rapid-PVST transition. This bidirectional hello mechanism helps prevent looping conditions caused by unidirectional links or a malfunctioning switch.

Bridge assurance works in conjunction with the┬áspanning-tree port type┬ácommand. The default port type for all ports in the switch is “normal” for backward compatibility with devices that do not yet support bridge assurance; therefore, even though bridge assurance is enabled globally, it is not active by default on these ports. The port must be configured to a spanning tree port type of “network” for bridge assurance to function on that port. Both ends of a point-to-point Rapid-PVST connection must have the switches enabled for bridge assurance, and have the connecting ports set to type “network” for bridge assurance to function properly. This can be accomplished on two switches running NX-OS, with bridge assurance on by default, and ports configured as type “network” as shown below.

To verify that bridge assurance is enabled globally, use the following command:

dcb-n7k1# show running-config all | include assurance

spanning-tree bridge assurance

Port channel between two Nexus 7010s with ports set as type network:

interface port-channel99

  switchport

  switchport mode trunk

  switchport trunk allowed vlan 128-133,151-153,161-167,180-183

  switchport trunk allowed vlan add 300-399,770-771

  spanning-tree port type network

  spanning-tree guard loop

  logging event port link-status

  description <link to n7k2>

Spanning tree bridge assurance as of this validation effort is only available in Cisco NX-OS. Integration of the Nexus 7000 aggregation layer with Cisco Catalyst 6500 and 4948 switches running Cisco IOS was accomplished by leaving the connecting ports set as their default spanning tree port type of “normal”, effectively not enabling bridge assurance on the ports.

 

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/nx_7000_dc.html#wp873732

http://blog.ciscoinferno.net/bridge-assurance

https://supportforums.cisco.com/thread/2000819

Compatibility with 802.1D from Understanding Rapid Spanning Tree Protocol (802.1w)

Compatibility with 802.1D

RSTP is able to interoperate with legacy STP protocols. However, it is important to note that the inherent fast convergence benefits of 802.1w are lost when it interacts with legacy bridges.

Each port maintains a variable that defines the protocol to run on the corresponding segment. A migration delay timer of three seconds also starts when the port comes up. When this timer runs, the current STP or RSTP mode associated to the port is locked. As soon as the migration delay expires, the port adapts to the mode that corresponds to the next BPDU it receives. If the port changes its mode of operation as a result of a BPDU received, the migration delay restarts. This limits the possible mode change frequency.

146-r.gif

For instance, suppose Bridges A and B in the preceding figure both run RSTP, with Switch A designated for the segment. A legacy STP Bridge C is introduced on this link. As 802.1D bridges ignore RSTP BPDUs and drop them, C believes there are no other bridges on the segment and starts to send its inferior 802.1D-format BPDUs. Switch A receives these BPDUs and, after twice hello-time seconds maximum, changes its mode to 802.1D on that port only. As a result, C now understands the BPDUs of Switch A and accepts A as the designated bridge for that segment.

146-s.gif

Notice in this particular case, if Bridge C is removed, Bridge A runs in STP mode on that port even though it is able to work more efficiently in RSTP mode with its unique neighbor B. This is because A does not know Bridge C is removed from the segment. For this particular (rare) case, user intervention is required in order to restart the protocol detection of the port manually.

When a port is in 802.1D compatibility mode, it is also able to handle topology change notification (TCN) BPDUs, and BPDUs with TC or TCA bit set.

 

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml