Spanning-Tree Backbone Fast

Hi Srini,

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.


Hi Rene,
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.

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 available? because Switch B is claiming he's the new root bridge, so Switch C just want to verify if root bridge is still alive)
  • now, if Switch C receives a response on his RLQ, it means the root bridge is alive right? then on Switch C's block port, it will skip the max age timer (20secs) and it will go straight listening mode then learning.
is this right? if this is right, then i have a question,

what if Switch C sends a RLQ and didnt receive a response? what will happened? Switch B will be the new root bridge? what is the process?

or i think it will not go through this long process, because not receiving a RLQ response means the RootBridge is dead right? it means directly connected port of Switch C to RootBridge will also detect a link failure, also Switch B will detect a link failure.

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, then in forwarding state, C will inform B that Root bridge is alive.

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 reply, we know the root bridge is gone and we’ll have to recompute STP.


1 Like

Hlw Rene,

SwitchC will receive these BPDUs from SwitchB but it will realize that this new BPDU is inferior compared to the old one it has currently stored on its fa0/16 interface.

From above the line of you…

Switch C will receive inferior BPDU (Best Bridge ID) on port Fa0/16 ?? If so then How ?? In My understanding, Switch A Originate BPDU and send to Down side and down side switch will carry the BPDU to other by using its Designated port . So Switch C will get Root Originated BPDU on its ports Fa0/14 and Fa0/16 and stored on port .

When SWA to SWB link down then SWB originated BPDU and send to SWC .If SWB originate BPDU then How its Lowest Bridge ID than Old one on port SWC fa0/16 ??

Please correct me if my understanding is wrong .Thanks


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 MAC Address. The lower the Bridge ID, the better–as far as being elected as the Root Bridge. Since in this example all switches have the same priority, it is the MAC address (the lowest MAC) which determines the Root Bridge. Switch C sees BPDUs coming from “BBB” and from “AAA” both claiming to be root. Switch B knows that AAA is lower than BBB, so it ignores BBB.

After 20 seconds of not receiving any more BPDUs from AAA on its port Fa0/16, Switch C transitions from Blocking to Listening to Learning to Forwarding. Only after all that happens (50 seconds, maximum), will Switch C send an “AAA” BPDU to Switch B. It is at this point that Switch B realizes its mistake (that it shouldn’t have claimed to be the Root Bridge). During this entire 50 second process, user data cannot leave switch B, so there would be an outage. Backbone-Fast is meant to minimize this outage.

Hi ,

i don’t understand how it can skip the max age timer as soon as SwitchC received a response from the root bridge on its fa0/14 interface . i am not very familiar with spanning tree . what is this responce(rlq) that get from the root bridge ; i thought that every two seconds get BPDU from the root bridge.

please correct me

Hello Dionisis!

The Backbone Fast function is designed to skip the max age timer. That’s one of the purposes of its implementation. As a result of the Backbone Fast implementation, INSTEAD of the max age timer, switch C sends a Root Link Query (RLQ) from port Fa0/14 asking if the root bridge is there. If it gets a reply, then it knows it’s there and 20 seconds of waiting are saved!

In this way, this allows it to quickly reinstate the link to the root bridge and begin functioning normally again.

I hope this was helpful!


Hi Rene,

so the best thing to do on a switch is to enable uplink-fast and backbonefast together, right?

Hi Samer,

It’s best to use PVRST. Uplink fast and backbone fast are two enhancements for “classic” spanning-tree. Rapid spanning tree has similar mechanisms so you don’t need to configure this anymore.


1 Like

SW1 receives a new packet called a (RLQ) Root Link Query from SW3. As soon as SW3 receives an inferior BPDU it will send a root link query on its root port and non-designated ports to check if the root bridge is still available.

Is this true? It will send an RLQ on non-designated ports?

Hello Jeremy

An RLQ request is sent out on a port where you usually receive BPDUs, in order to check that you still have connectivity to the root through this port. This is confirmed by this Cisco documentation.

I’ll inform Rene to take a look and make any necessary changes.

Thanks for catching that!


Yes, it sends an RLQ on all non-designated interfaces, except the one where it receives the inferior BPDU on.

Hello Rene,

In this scenario, where the link between sw1 and sw2 is down, would it lead to root bridge re-election?

Hello Varun

The only situation in which a root bridge re-election will take place is if:

  1. A BPDU is received on the network which has a lower BID than that of the current root bridge
  2. The current root bridge has failed, has stopped sending BPDUs, and after a timeout, all of the remaining switches consider the root bridge as down, and begin a re-election process.

Neither of the above situations is reproduced in this scenario. Of course, once the connection between SW1 and SW2 is down, SW2 will temporarily be cut off from the root bridge. The process of re-convergence however is fast enough to occur before SW1 considered the root bridge as down to begin a re-election process.

I hope this has been helpful!


Hi Rene/Laz,

Same question here, is this can only be used in case of indirect link failure?

Q2 ) As per topology used to describe this topic, If link b/w SW3 and SW1 get failed rather than SW3 and SW2 then will this still act as a indirect link failure ?

Hello Pradyumna

Backbonefast, like Uplinkfast, is used in case of an indirect link failure. However, this indirect link failure does not only have to occur on a link connected to the root bridge, it can take place anywhere on the network.

It depends on the “point of view”. For SW3, a failure of the SW1-SW2 link is an indirect link failure. In other words it doesn’t occur on one of its ports. For SW2, a failure of the SW1-SW3 link is an indirect link failure, because the failure doesn’t occur on one of its ports.

I hope this has been helpful!