Spanning Tree Backbone Fast

Backbone Fast is used to recover from an indirect link failure. What does that mean? Let me show you an example of an indirect link failure and how spanning tree deals with it:

Take a look at the picture above. SW1 is the root bridge, and the fa0/16 interface on SW3 has been blocked. Suddenly, the link between SW1 and SW2 fails. From SW3’s perspective, this is an indirect link failure.

This is what will happen:

1. SW2 will immediately detect this link failure since it’s directly connected. Since it doesn’t receive any BPDUs from the root anymore, it assumes it is now the new root bridge and will send BPDUs toward SW3, claiming to be the new root.
2. SW3 will receive these BPDUs from SW2, but it will realize that this new BPDU is inferior compared to the old one it has currently stored on its fa0/16 interface and will ignore this new BPDU. When a switch receives an inferior BPDU, it means that the neighbor switch has lost its connection to the root bridge.
3. After 20 seconds (default timer), the max-age timer will expire for the old BPDU on the fa0/16 interface of SW3. The interface will go from blocking to the listening state and will send BPDUs towards SW2.
4. SW2 will receive this BPDU from SW3 and discovers that he isn’t the root bridge. It won’t send BPDUs anymore towards SW3.
5. The fa0/16 interface on SW3 will continue from the listening state (15 seconds) to the learning state (15 seconds) and end up in the forwarding state.

Connectivity is now restored, but it took 20 seconds for the max-age timer to expire, 15 seconds for the listening state, and another 15 seconds for the learning state before we go to the forwarding state. That’s a total of 50 seconds of downtime. Let’s take a look at this situation on our switches. I will enable a debug:

SW2#debug spanning-tree events 
Spanning Tree event debugging is on

SW3#debug spanning-tree events 
Spanning Tree event debugging is on

And let’s shut down the interface to simulate an indirect link failure:

SW1(config)#interface fa0/14
SW1(config-if)#shutdown

SW2 believes it is the root bridge:

SW2# STP: VLAN0001 we are the spanning tree root

And SW3 receives the BPDU from SW2, who claims to be the root bridge:

SW3# STP: VLAN0001 heard root  8193-0019.569d.5700 on Fa0/16
SW3# STP: VLAN0001 Fa0/16 -> listening
SW3# STP: VLAN0001 Fa0/16 -> learning
SW3# STP: VLAN0001 Fa0/16 -> forwarding

After the max age timer expires (20 seconds) for the old BPDU from SW2, the fa0/16 interface on SW3 will go to the listening and learning state and end up in the forwarding state. A bit later, we see this:

SW2# STP: VLAN0001 heard root 4097-0011.bb0b.3600 on Fa0/16
SW2# STP: VLAN0001 new root is 4097, 0011.bb0b.3600 on port Fa0/16, cost 38

The identity crisis of SW2 comes to an end. It now hears the BPDUs from the root bridge through SW3 and understands that it’s not the root bridge.

Without backbone fast, spanning tree will discard the inferior BPDUs that SW3 receives on its fa0/16 interface, and it will have to wait till the max age timer expires (20 seconds).

If we enable backbone fast, it will skip the max age timer, so we can save 20 seconds. Let’s restore that interface:

SW1(config)#interface fa0/14
SW1(config-if)#no shutdown

And we’ll enable backbone fast:

SW1(config)#spanning-tree backbonefast

SW2(config)#spanning-tree backbonefast

SW3(config)#spanning-tree backbonefast

This is a global command. To see this in action, we’ll enable some more debugging: