Hello Florian
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.
Question 3:
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.
Question 4:
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!
Laz