Uplinkfast is a spanning tree feature that was created to improve the convergence time. In this lesson, we’ll take a look at how UplinkFast works. Here’s the topology that I will use to demonstrate it:
Three switches and SW1 is our root bridge. The fa0/16 interface on SW3 has been blocked. I’m only using VLAN 1, so nothing fancy here…
If we look at SW3 we see that the fa0/16 interface has been blocked and fa0/14 is the root port. Let’s see what happens with this topology when one of the links fails:
When the fa0/14 interface on SW3 fails, we’ll have to use fa0/16 to reach the root bridge. How long does it take for SW3 to make the transition? Let’s find out:
SW3#debug spanning-tree events
Spanning Tree event debugging is on
SW3(config)#interface fa0/14
SW3(config-if)#shutdown
Now, we’ll just wait for the magic to happen…
SW3#STP: VLAN0001 new root port Fa0/16, cost 38
SW3#STP: VLAN0001 Fa0/16 -> listening
SW3#STP: VLAN0001 Fa0/16 -> learning
SW3#STP: VLAN0001 Fa0/16 -> forwarding
BPDUs are originated from the root bridge so if we receive BPDUs on an interface the switch knows it can reach the root bridge on this interface. We have to go through the listening (15 seconds) and learning state (15 seconds) so it takes 30 seconds to end up in the forwarding state.
The good thing is that spanning tree solves the link failure automatically but it also means that we have a downtime of 30 seconds. If you want you can tune the forward delay timer to speed up this process down to roughly 14 seconds.
SW3(config)#interface fa0/14
SW3(config-if)#no shutdown
Let’s restore connectivity first.
SW3(config)#spanning-tree uplinkfast
Now, I’m going to enable spanning-tree uplinkfast
. This is a global command, you can’t configure it on the interface level.
SW3(config)#interface fa0/14
SW3(config-if)#shutdown
SW3# STP: VLAN0001 new root port Fa0/16, cost 3038
SW3# %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 FastEthernet0/16 moved to Forwarding (UplinkFast).
Here’s the big difference. When uplinkfast is enabled a non-designated port will go to forwarding state immediately if the root port fails. Instead of 30 seconds of downtime, connectivity is restored immediately.
UplinkFast is useful, but it will cause a problem with our MAC address tables. In the picture above, I added two computers to our topology. Interface fa0/16 on SW3 is the non-designated port, and fa0/14 is the root port. Take a look at the following topology:
Let me show you the MAC address tables for all switches:
SW1#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/14
1 000c.29e2.03ba DYNAMIC Fa0/17
SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/2
1 000c.29e2.03ba DYNAMIC Fa0/14
SW3#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/14
1 000c.29e2.03ba DYNAMIC Fa0/3
Here are the MAC addresses of the computers:
- H1: 000c.2928.5c6c
- H2: 000c.29e2.03ba
When the link between SW1 and SW3 fails, SW3 will use the fa0/16 interface immediately. However, it will take 15 seconds for the topology change mechanism to age out the MAC address table!
SW2#show mac address-table dynamic
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
1 000c.2928.5c6c DYNAMIC Fa0/2
1 000c.29e2.03ba DYNAMIC Fa0/14
Take another look 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…).
Of course, we have a solution to speed this up. Here’s what we will do:
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.
Hi Humberto,
A long time ago, Cisco created Uplink Fast and Backbone Fast to “enhance” the old classic spanning-tree version (802.1D) . These two features were proprietary.
RSTP (802.1w) has something similar to Uplink fast and Backbone fast integrated in it so there’s no need to enable Uplink / Backbone fast. This was only nice to use for the old 802.1D version of spanning-tree.
Does this help?
Rene
Of course.
Thank you very much!!!
Humberto
Rene,
Hi. Can you please further clarify the following:
"BPDUs are originated from the root bridge so if we receive BPDUs on an interface the switch knows it can reach the root bridge on this interface. We have to go through the blocking (20 seconds), listening (15 seconds) and learning state (15 seconds) so it takes 50 seconds to end up in the forwarding state.
The good thing is that spanning-tree solves the link failure automatically but it also means that we have a downtime of 30 seconds. If you want you can tune the forward delay timer to speed up this proc
... Continue reading in our forumHi Thomas,
I just fixed this, it’s 30 seconds. It has to go through the listening (15) and learning (15) states so it’s 30 seconds in total.
Rene