Spanning-Tree UplinkFast

Hi all,

in the initial setup the port fa0/16 on SW3 is in ND/blocking state, why does it only need 30sec to move to forwarding state?
I would guess that it would stay 20sec in blocking before moving through the other states, no?



Hello Florian.

As soon as SW3 realizes that the current root port fa0/14 is in a down state, then the fa0/16 port immediately goes into the Listening state for 15 seconds, and then to the Learning state. During those two states, it should recieve BPDUs from the root bridge on fa0/16 and once the 30 seconds are up, it will become the new root port and it goes into the forwarding state.

The key here is that the port will not remain in the blocking state, but will immediately change to the Listening and learning states once the current root port fails.

I hope this has been helpful for you!


Hi Laz,

thanks for your answer!
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!?



Hi Laz,

just read the article again and now iam a bit confused…

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?



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!


Hi Laz,

thanks a lot.



19 posts were merged into an existing topic: Spanning-Tree UplinkFast

So I have a question on this. it is stated that dummy multicast are flooded out all ports that contain the switch with the broken links Mac address table. in addition this mechanism will cause the 20 second timer enacted by the topology table to stop and the other switches can go to receiving the new mac address information immediately. quote from web lesson:

Take a look again at the MAC address table for SW2. The MAC address (000c.29e2.03ba) that I highlighted belongs to H2. When SW2 receives an Ethernet Frame for H2 it will be forwarded to SW1 and it will be dropped! (Well at least for 15 seconds until the topology change mechanism kicks in…).

I tend to really learn when I have to explain this back to myself or another person as if I was teaching. When I did so the I saw an inquisitive explorative question that might arise if we just did not take something as fact because it was said.


why does the dummy multicast cause the switches to stop holding those MAC addresses contained within the dummy multicast??? why does it not drop the dummy multicast like it does in the quote above from the web lesson??

Now if asked this I would simply say because the dummy multicast are a special address that the switches recognize so they simply drop those from its aging table and then they are able to receive.

however, I am just making the most logical guess that I can make as I did not see that posted anywhere. the true answer would be I don’t know for certain.

Anyway diving deep into questions like this helps me to remember the content better as its all embedded behind the reasoning and must be known to get to this point so I figured why not ask =)

I actually am being naughty, I have not read my book or tried to watch the videos to see if they state this detail. so I am being lazy. What I will do is this; I will go back read my book and try to go through and find the answer they give in my video and post here. I think its worth having the question on the forums as others can benefit as well. If someone provides an answer here before I can get back and post that’s great to as I a:) may not be able to find my answer or b:) will confirm what I find when I come back to post my findings!

Ok first information non related to my question but I will post as its useful:

Configuring Uplink Fast Uplink Fast is enabled on Access layer switches and keeps track of possible paths to the Root Bridge. Once the Uplink Fast feature is enabled globally, it is enabled for the entire switch and all VLANs. By default, when Uplink Fast is enabled, Cisco IOS software performs the following actions on the local switch:

  • The Bridge Priority of the switch is raised to 49,152
  • The Port Cost of all VLANs is increased by 3,000

These two actions ensure that the switch will never be elected Root Bridge, and it makes the path through this switch as undesirable as possible for any downstream switches. For this reason, Uplink Fast should never be enabled on the Root Bridge because it will lose its Root status or lose switches that have other downstream switches connected to them.

Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Locations 2588-2596). Reality Press Ltd. Kindle Edition.

Next is the answer to my question. was not in the book basically the same as the web lesson it did have a extra piece of information or two:

By transitioning the port to a Forwarding state almost immediately, the Uplink Fast feature presents the potential problem of incorrect entries in the CAM tables of the other switches because they have not had an opportunity to re-learn the new path for the MAC addresses of the devices connected to the Access switch.

To prevent this, the Access layer switch on which the Uplink Fast feature is enabled floods dummy frames with the different MAC addresses that it has in its CAM as a source. The frames are sent to the Multicast address 01-00.0C-CD-CD-CD and appear to originate from the hosts connected to the switch so all the upstream switches can learn of these addresses through the new port.

By default, the switch sends out these Multicast frames at a rate of 150 packets per second (pps). However, this value can be adjusted by using the spanning-tree uplinkfast max-update-rate [rate] global configuration command.

Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Locations 2618-2620). Reality Press Ltd. Kindle Edition.

so next I will try to scan through my INE CCNP video and see if they mention the answer to my question!


They did not give an answer on INE as well they just said it sent dummy multicast and that fixed it. so I am only left to guess that it fixes it and is not dropped because the address is special and the software code says hey when you see this address drop the MAC addresses and add these Mac addresses from this location or maybe it does not drop but just changes but the effect is the same.

if someone is able to find this answer feel free to post at least I now did my due diligence in trying to find the answer!

note: I did find the following it does not spell out the answer of how either, it does once again logically suggest that the “how” is because its a special address and strengthens it with terms such as “ensures” ect…

In order to solve this problem, switch A begins to flood dummy packets with the different MAC addresses that it has in its CAM table as a source. In this case, a packet with C as a source address is generated by A. Its destination is a Cisco proprietary multicast MAC address that ensures that the packet is flooded on the whole network and updates the necessary CAM tables on the other switches.

Interesting lesson ; but, some potential confusing points to be clarified.

* Point-1

In one of the previous lessons (TCN), it was said about 50s delay for moving from Blocking to Forwarding state. This lesson does only talk about 30s delay. Something important that this lesson has to say is : SW3 does not need to wait for the 20s of “Max Age” (parameter setting on the switch) ; because it detects immediately that a port (belonging to the switch) is not working.

* Point-2

The lesson is saying that the Listening and Learning delay could be as lower as 14s. It would be important to recall that this delay is always twice (2 x 7s) the “Forward Delay” parameter (setting on the switch).

* Point-3

The end of the lesson is very confusing. Once the link between SW3 and SW1 is back ; nothing explains by which process and how long it takes for the ports of those two switches to get back to their former states.

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!


About my Point-3, I’m still confused about the status of SW1-fa0/17 and SW3-fa0/14 (while and after the link failure).

- Why the link failure is detected only on SW3 side and not on SW1 side ?
- How come SW1 did nothing with fa0/17 when it gets TCN from SW3 (fa0/17 stays in “D” status) ?
- Why did SW3 not send a TCN to SW1 (ROOT) after the link is repaired ?

It is also hard for me to understand the consistency between the last schema and the last debug informations. The schema says nothing about ports fa0/14 and fa0/16 on SW3 ; but, the debug information says : fa0/14 -> blocking, new root port fa0/14 -> , fa0/16 -> blocking. Does SW3 tries to return immediately to the state before failure ?

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!


Does sw3fa0/16 going forwarding create a TCN as well and we don’t require the dummy multicast frame? or this is classic stp with uplinkfast enable and not RSTP?

The rstp lesson mentions:
With the classic spanning tree a link failure would trigger a topology change. Using rapid spanning tree a link failure is not considered as a topology change. Only non-edge interfaces (leading to other switches) that move to the forwarding state are considered as a topology change ( in this case sw3 fa0/16). Once a switch detects a topology change this will happen:
•It will start a topology change while timer with a value that is twice the hello time. This will be done for all non-edge designated and root ports.
•It will flush the MAC addresses that are learned on these ports.

Hello Ignacio

When the link fails, SW3 will indeed send a TCN. If you notice earlier in the lesson, just before the multicast frame mechanism is explained, Rene mentions this:

So without the dummy multicast frame mechanism, the flushing of the MAC address table will take 15 seconds due to the TCN, as opposed to the 300 seconds it would normally take. However, the dummy multicast frame improves upon this by updating the MAC address tables of the connected switches almost instantaneously.

I hope this has been helpful!


port fa0/16 on SW3 was on blocking mode. why did it transition 30 seconds instead of 50 seconds?

Then in what situation does Max age timer plays a role?

Hello Thierno

There are two situations where the re-convergence takes place. The first is in the case of the lesson, where when port fa0/14 is shutdown, there is a complete carrier loss. In this case, the port with the best BPDU information is immediately invalidated. This means that the next best port is immediately chosen, which is fa0/16 without delay, so no 20 seconds are wasted in blocked mode. This is why the transition took 30 seconds, 15 in listening and 15 in learning.

Now if there were another switch between SW1 and SW3, and that switches connection to SW1 failed, fa0/14 would still be active, so no immediate loss of connectivity would be detected by SW3. This means that the whole BPDU exchange process would have to inform SW3 that more valid BPDUs are being received now from fa0/16, so it would then transition using the blocked>listening>learning procedure of 50 seconds.

I hope this has been helpful!


Hello Thierno

The Max_age timer plays a role when the current root port of the local switch is still up, but a failure has occurred somewhere else upstream. Only then will the Max_age timer need to be exhausted before a port considers the last BPDU it has received invalid. This is also related to the previous post:

I hope this has been helpful!


Hello Laz,
then what is the purpose of the Max Age timer if the port fa0/16 will move directly to the listening state after that the switch realizes that fa0/14 went down?
My undestanding (and please correct me if I am wrong) is that by default the switch will wait for 20 seconds for fa0/14 to come up again. Only after that the switch will start with the STP recalculation.

Hello Fadi

In the scenario that is being described, the port that actually goes down (Fa0/14 on SW3) is on the same switch as the port that is changing state (Fa0/16 on SW3). This means that the switch immediately knows that the current root port is no longer valid, therefore it doesn’t wait for the extra 20 seconds.

If the port that goes down is found on another switch that is upstream in relation to SW3 and the root bridge, then the switch does not immediately know that it’s ND port should begin changing state, so it waits the extra 20 seconds making the total wait time 50 seconds…

I hope this has been helpful!


1 Like