Notable Replies

  1. Hi Rene, excelent post.
    However, I have some doubts about this topic. I read that using RSTP we have some improvements similar to Uplink and Backbone Fast. So, we don´t have to use this features on RSTP. Is that correct?

    This output was taken from a Cat3750: “UplinkFast is enabled but inactive in rapid-pvst mode”
    Can you help me with this??

    Whatever, your example is fantastic.

  2. Hlw Rene,

    Nice explanation in right WAY, GREAT !

    So , if we use Uplinkfast then no downtime occure ?? So how SWITCHC will update its MAC table as SWITCHB updated its MAC table using Multiicast Frame sending by SWITCHC ? I think there is 15 sec downtime needed due MAC table flush in SWITCHC.

    Another Questions …After STP convergence , Only Root Bridge will send BPDU(Hello time interval) and other SWITCH will receive BPDU [if no Topology Chage].


  3. Hello florian.

    To answer your first question:

    But this is only the case if uplink-fast is configured, right?
    If it is not configured the port would stay in block state for 20 sec and then move through the other states!?

    Yes, my description in the above post is for situations where uplinkfast is not implemented. In case uplinkfast is configured, this is reduced from 30 seconds to almost 0 seconds. Cisco explains it like so:

    The UplinkFast feature is based on the definition of an uplink group. On a given switch, the uplink group consists of the root port and all the ports that provide an alternate connection to the root bridge. If the root port fails, which means if the primary uplink fails, a port with next lowest cost from the uplink group is selected to immediately replace it.

    This is found at

    Concerning your second question:
    When does a port actually stay in blocking state before it moves to listening and so on?
    If the root port is down the blocking interface goes directly to listening?
    And Uplink-fast just helps to move the port directly to forwarding, right?

    A port remains in blocking state as long as there is another active path to the root bridge. To say it another way, a port remains in blocking state when STP has converged. If there is a topology change, ports do not remain in a blocked state for any period of time before moving to listening and learning. So yes, “if the root port is down, the blocking interface goes directly to listening” in normal STP operation. If you use uplinkfast, the listening and learning states are skipped.

    It is only during root bridge elections that a port remains in a blocking state for 20 seconds. If a topology change occurs but the root bridge does not change, then this extra blocking state for 20 seconds is skipped.

    A very clear step by step explanation can be found here:

    Uplink failure without uplinkfast enabled:

    Uplink failure with uplinkfast enabled:

    I hope this has been helpful!


  4. Hello Maodo

    In the TCN lesson, it mentions that there will be a maximum of 50 seconds delay when there is a change in topology. When a TCN is received, a port will go into the blocking state for the Max Age interval which is an interval of 20 seconds by default before beginning the STP recalculation. The maximum of 50 seconds is ONLY for topology changes.

    In this lesson, it is mentioned that it takes a maximum of 30 seconds for STP to converge when STP function occurs from scratch, that is, after the switches are rebooted or turned on. This includes ONLY the Listening (15s) and Learning (15s) states. In this case, 30 seconds is only needed.

    How the result of approximately 14 seconds has been achieved depends on several factors including network diameter. For further information, you can check this Cisco documentation that further explains STP timers in detail.

    As is stated in the lesson, essentially nothing happens. The root port remains the same and Fa0/14 remains blocked. Since the network is currently working, no changes have been made, BPDUs are successfully exchanged, the network remains in this state until there is a topology change.

    I hope this has been helpful!


  5. Hello Maodo

    The link failure is also detected on SW1 however, the example examines the behaviour of the ports on SW3.

    In the diagram, @ReneMolenaar still has the (D) showing up on port fa0/17 on SW1, and this should be removed. I will inform him…

    SW3 does sent a TCN to SW1 but not necessarily immediately. Note the SW3# STP: VLAN0001 Fa0/14: root port delay timer active debug line.

    The last diagram does not indicate what the states of the ports on SW3 are in order to make a point of determining them from the debug. As mentioned in the text: "You can see we don’t immediately switch back to interface fa0/14. There’s no reason to switch back to this interface ASAP because we have a working root port."

    Eventually, the Fa0/16 does become blocked and the Fa0/14 does become the root port with a cost of 3019.

    I hope this has been helpful!


Continue the discussion

41 more replies!