Lesson Contents
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.
Configuration
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.
Hello Rene,
If I understand Rapid-PVST+ correctly, with rapid-pvst+ configured, it syncs with its neighbors by sending BPDU every hello time interval as a keep alive. Does Bridge assurance play a role with rapid-pvst+? Or by natural it’s not supported in rapid-pvst+ as it’s not needed?
Thanks!!
Hello Ray
As mentioned by Rene, bridge assurance is only supported by PVRST+ and MST. PVRST+ is the same as Rapid PVST+. So to answer your question, bridge assurance does indeed play a role and it is supported. Note in the following Cisco documentation of the bridge assurance command that it states that it is compatible with Rapid PVST+ and MST.
https://www.cisco.com/c/m/en_us/techdoc/dc/reference/cli/nxos/commands/l2/spanning-tree-bridge-assurance.html
I hope this has been helpful!
Laz
Thanks Laz!
Isn’t BA built-in in PVRST+ ? By defualt, it syncs with its neighbors by sending BPDU every hello time interval as a keep alive. Why do we need a separate command to enable it ?
Hello Ray
Depending on the platform, the default state of bridge assurance may differ. On the 6500 series for example, bridge assurance is enabled globally by default and is enabled only on spanning tree network ports that are point to point links. On Nexus switches, it is enabled globally but disabled on individual ports and must be manually enabled.
The feature is specifically used to protect against a unidirectional link failure or other software failure and against a device that may continue to forward data traffic when it is no longer running the spannin
... Continue reading in our forumHello Rene,
whats the difference between loopguard and bridge assurance?
Thanks a lot.