Spanning-tree Bridge Assurance is one of those STP features that help to prevent bridging loops in your network. When bridge assurance is enabled, BPDUs are sent on all interfaces of your switch, including blocked interfaces like the alternate or backup port. When an interface doesn’t receive a BPDU for a certain time, the interface goes into the blocking state.
Once the interface receives BPDUs again, the interface is unblocked and goes through the normal spanning-tree port states again. This helps to prevent issues (ie, unidirectional link failures or switch failures where the switch does forward ethernet frames, but STP is malfunctioning) where for whatever reason, an interface doesn’t receive BPDUs again, and a blocked interface goes into the forwarding state, causing a bridging loop.
Bridge assurance is only supported by PVRST+ and MST.
In this lesson, I’ll show you a “before” and “after” scenario, and we will look at bridge assurance in action.
Without Bridge Assurance
Let’s see how spanning-tree works when we don’t use bridge assurance. We have the following topology:
SW1 is our root bridge, and it sends BPDUs on both interfaces. SW2 has the designated port on the interface that connects to SW3, so the GigabitEthernet 0/2 interface on SW3 is the alternate port and blocking. Suddenly, SW2 stops sending BPDUs on its GigabitEthernet 0/2 interface:
Because SW3 doesn’t receive superior BPDUs anymore on its GigabitEthernet 0/2 interface, it decides that the interface becomes a designated port and it forwards data. We now have a bridging loop:
That’s not good…let’s see what happens with bridge assurance.
With Bridge Assurance
We use the same topology as before:
The difference, however, is that when bridge assurance is enabled, every interface sends BPDUs. Once again, SW2 has a failure, so it’s no longer sending BPDUs:
SW1 and SW3 notice the lack of BPDUs and immediately put their interfaces in the blocking state. This saves the day as there won’t be a bridging loop.
Bridge assurance is supported on Cisco IOS since version 12.2(33)SXI, but it seems to be only available on the Cisco catalyst 6500 series. I’m using three Nexus switches to demonstrate bridge assurance. If you never worked with NX-OS before, don’t worry.
The output is pretty much the same as on Cisco IOS. This is the topology:
Bridge assurance is enabled globally by default on NX-OS:
NX1# show running-config all | include assurance spanning-tree bridge assurance
However, we do have to change the spanning-tree port type to network on all interfaces to activate it:
NX1(config)# int e1/28, e1/32 NX1(config-if-range)# spanning-tree port type network
NX2(config)# int e1/30, e1/32 NX2(config-if-range)# spanning-tree port type network
NX3(config)# int e1/28, e1/30 NX3(config-if-range)# spanning-tree port type network
That’s all we have to configure.