This topic is to discuss the following lesson:
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.
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.
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.
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.
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.
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
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!
so the best thing to do on a switch is to enable uplink-fast and backbonefast together, right?
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.
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?
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.
In this scenario, where the link between sw1 and sw2 is down, would it lead to root bridge re-election?
The only situation in which a root bridge re-election will take place is if:
- A BPDU is received on the network which has a lower BID than that of the current root bridge
- 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!