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:
- SW2 will detect this link failure immediately since it’s a directly connected link. Since it doesn’t receive any BPDUs from the root anymore it assumes it is now the new root bridge and will send BPDUs towards SW3 claiming to be the new root.
- 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.
- 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.
- SW2 will receive this BPDU from SW3 and discovers that he isn’t the root bridge. It won’t send BPDUs anymore towards SW3.
- The fa0/16 interface on SW3 will continue from the listening state (15 seconds) to the learning state (15 seconds) and ends 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 downtime. Let’s take a look at this situation on our switches:
SW2#debug spanning-tree events Spanning Tree event debugging is on
SW3#debug spanning-tree events Spanning Tree event debugging is on
Let’s enable our debugging.
SW1(config)#interface fa0/14 SW1(config-if)#shutdown
I will shut this interface to simulate an indirect link failure.
SW2# STP: VLAN0001 we are the spanning tree root
SW2 believes it is the root bridge.
SW3# STP: VLAN0001 heard root 8193-0019.569d.5700 on Fa0/16
SW3 receives the BPDUs from SW2 who claims to be the root bridge.
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 ends up in forwarding state.
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 of time.
SW1(config)#interface fa0/14 SW1(config-if)#no shutdown
Let’s enable the fa0/14 interface on SW1 first.
Let’s enable backbone fast on all switches. This is a global command (spanning-tree backbonefast).
In my understanding , ND port can only receive BPDU . With Backbone fast enabled,
How does switch C send RLQ on both the Root port and ND port ? RLQ is not a BPDU frame ?
Please explain RLQ.
The RLQ is not send on the ND port, only the root port. The last message is a bit cryptic, it means that SwitchC received a reply on its root port that it sent because it received an inferior BPDU on its ND port.
Thanks for explainig RLQ in RSTP.
Uplinkfast and Backbone fast are they used together in conjunction?
In the past yes, these were used for PVST.
RPVST has similar built-in mechanisms so you don’t have to enable these nowadays.