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:

spanning tree indirect link failure

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 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.
  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 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

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.

SW1(config)#spanning-tree backbonefast
SW2(config)#spanning-tree backbonefast
SW3(config)#spanning-tree backbonefast

Let’s enable backbone fast on all switches. This is a global command (spanning-tree backbonefast).

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 710 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

466 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. In the past yes, these were used for PVST.

    RPVST has similar built-in mechanisms so you don’t have to enable these nowadays.

  2. let me clarify this, correct me if im wrong. this is what i understand on this lesson

    • Link between Sw A and Sw B is down. so Switch B will not receive any BPDU's from root bridge, claiming he's the root bridge.
    • since the link between A and B is down, Switch B's BPDU will send through Switch C.
    • Now switch C receives this BPDU and identifies it as inferior BPDU.
    • Since it receives an inferior BPDU, Switch C will send a Root Link Query on its Root Port to check if the root bridge is still available (this is the purpose of RLQ? to check if root bridge is availa
    ... Continue reading in our forum

  3. i think i get it now, i reread it. so without backbonefast, Switch C will drop the inferior BPDU produced by Switch B. since the link A-B is down, Switch C f0/16 is not receiving the old BPDU so it will wait for the max age time to expire (20secs), then it will now go to listening and learning state.

    when backbonefast is enabled, switch C will not drop/ignore the inferior BPDU, C will send a RLQ to the root bridge, then if C receives a response, it means root bridge is alive, then it will skip the max age time on F0/16 then will go to listening and learning, th

    ... Continue reading in our forum

  4. Hi John,

    All steps that you described are correct, that’s how it works.

    SwitchB doesn’t have a link to the root bridge so it claims to be the new root bridge. SwitchC which is still connected to the root doesn’t agree so it drops the inferior BPDU from SwitchB.

    We want to get rid of the max age timer, that’s 20 seconds so instead we let SwitchC do a quick “check” to see if the root bridge is still reachable by sending a RLQ. When it receives a RLQ reply, it knows the root is still there and it can age out the interface immediately.

    In case you don’t get a RLQ r

    ... Continue reading in our forum

  5. Mohammad,
    Switch C receives an inferior BPDU (meaning a worse BPDU) on Fa0/16. This worse BPDU was created by Switch B because after Switch B’s link to Switch A went down, Switch B now believes it is the Root Bridge. Since it is the job of the Root Bridge to create BPDUs, Switch B is doing what it thinks is the proper activity. However, Switch C knows that Switch B is mistaken. It knows this because Switch C is still able to receive superior BPDUs (meaning better) from the true Root Bridge, Switch A.

    Bridge ID is determined by a combination of Priority and

    ... Continue reading in our forum

18 more replies! Ask a question or join the discussion by visiting our Community Forum