This topic is to discuss the following lesson:
Only one comment:
-Second scenary: BPDUs between SW2 and SW4: “Since SW2 temporarily claimed itself as the root bridge”, it should say “Since SW3 temporarily claimed itself as the root bridge”. Let me get to knoe im a mistake, thanks.
Yes as far as I can see you are correct. I will let @ReneMolenaar know to change it.
When the root bridge looses a connection like in the example shown, why does it not send a TCN?
Why only a TC trap is generated? It lost one of its designated ports. Or is that not a topology change from the roots perspective?
When a new root port is elected on a switch and the new root port is the former designated port, there is now listening/learning/forwarding process happening, right? Because the port did that already and is already in a “forwarding” state!? Only if a port is in blocking state or the port just came UP, correct?
The Root bridge never sends out TCNs because a TCN is used primarily to inform the root bridge of the topology change. More accurately, it is used to inform all switches between the topology change and the root bridge of the change. If a topology change occurs on the actual root bridge, it doesn’t need to send a TCN based on the above description. Note the following Cisco documentation:
When a port changes from Designated port (forwarding state) to root port (also forwarding state) it doesn’t have to go through the process of listening/learning/forwarding. It is already in the forwarding state and it remains so until it goes down and is brought back up or until it receives superior BPDU due to a topology change.
I hope this has been helpful!
thanks a lot for your answer!
I thought it might be faster for the root bridge to send a BPDU with the TC bit set right away when it realizes that a link is down, instead of waiting to hear from other switches in the network through a TCN and then sending the BPDU with the TC set.
I have two more questions.
Just read the “Spanning-Tree UplinkFast” article and at one point the ND port changes to become the new root port, but it only goes through listening/learning/forwarding. I thought a ND equals a blocking port and thus needs to wait 20sec before starting the listening/learning/forwarding process!?
The last part describes that even though the old root port is active again the switch does not change to that port right away. Why not? Is that a behavior caused by Uplinkfast or is it normal?
Because the best BPDU is received on that port so why does it not change?
Does it have to do that the port on SW1 needs 50sec to become active?
Thanks a lot for your help!
Concerning Question 1, if a root bridge learns about a topology change that is due to the change of state of its own interfaces, then it will immediately know of the topology change, so it does not actually have to “wait” to be informed by other switches. Once again, the TCN is sent to inform all the switches between the location where the topology change took place and the root bridge of the TC.
Yes you are correct that the ND port is indeed blocking. However, because its initial state is blocking, this state is not explicitly expressed in the debug output shown in the lesson. The debug output for blocking will only appear when the blocking state began, that is, when the port transitioned to the blocking state from whatever other state it was in. In the example in the lesson, the debug shows the change from blocking to listening, listening to learning, and learning to forwarding.
When the old root port is active again and uplinkfast is enabled, the behaviour of STP will be the following:
- Once the old root port is enabled, it receives superior BPDUs immediately
- The root port delay timer will kick in which is typically 35 seconds in which it remains in the listening state. It never actually goes into the learning state before entering the forwarding state
- The result is that the root port does not switch back immediately, but takes a delay to go back.
This is indeed a result of the configuration of the uplinkfast feature on the switch. If it switches back immediately, the Fa0/14 port will become the root port, but the corresponding port on the root switch will still take the typical amount of time to go through all of the STP states to become forwarding as well. So this avoids a temporary loss of connectivity.
For reference for the questions above, the link to the UplinkFast lesson is included below.
I hope this has been helpful!
Hi according to the result for the overview with the new port state and the diagram at the end . The Diagram and the " SW1#show spanning-tree | begin Interface " dont match .
Sw1 Gi0/2 Desg FWD 4 (on diagram doesnt even exist the interface its shut )
Thanks for pointing that out, I will let Rene know to fix the typo.
Do you mean this one?
I didn’t add a new topology picture with all interfaces up for this example. Maybe I should, it could be confusing like this. I only mention in the text that we start with a topology with two active interfaces on SW1.
Diagram for the last Logical Topology is not represented correctly by the outputs in the CLI. for instance SW5 Shows two different DES/RP information that doesn’t reflect in the Last Logical Topology you display. I believe the ports and their associated roles are mixed up. Gi0/1 shows itself as a Root port on SW5 on the CLI output but shoes it as a DES on the logical topology… that confused me…