STP as we know it, keeps the network loop free but at what cost? The exact cost to you and I is 50 seconds! That is a long, long time in networking terms. For almost a minute data cannot flow across the network. In most cases this is a critical issue, especially for important network services.
To deal with this issue (before the industry standard was ratified) Cisco added the following features to STP implementation on its switches:
- PortFast, BPDUGuard and BPDUFilter
- UplinkFast
- BackboneFast
Portfast
If you have a laptop or a server connected to a switchport then you know that:
- It will not need to listen to BPDUs because it is not a layer 2 device
- It will not create loops because it has a single link to the layer 2 network
Therefore, you can safely disable Spanning Tree on such ports. It is very important to ensure that such ports never have a STP enabled layer 2 device connected on them (Think port security!) or else a loop or a breakdown of the network is quite possible. You will even get a warning message on certain switches stating this when you enable portfast on a switchport!
When you configure a switchport as portfast, STP will be disabled on that port and it will transition to forwarding state when it comes up and will never be blocked.
The command to configure portfast is spanning-tree portfast:
SwitchA(config)#int fastEthernet0/44
SwitchA(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc… to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet0/44 but will only
have effect when the interface is in a non-trunking mode.
As we learned, Portfast disables STP on a switchport but an important fact is that a Portfast switchport will keep listening for BDPUs. If someone adds a switch to a port which has been configured as Portfast, the consequences will be unpredictable and is some cases disasterous.
To guard against this situation, Cisco provides the BPDUGuard and BPDUFilter features.
BPDUGuard
If a switch is plugged into a switchport configured as Portfast, it could change the STP topology without the administrator knowing and could even bring down the network. To prevent this, BPDUGuard can be configured on the switchport. With this configured, if a BPDU is received on a switchport, it will be put into an error disabled mode and an administrator will have to bring the port up. This can be configured on the port using the “spanning-tree bpduguard enable” command.
BPDUFilter
When BPDUFilter is configured on a switchport which has been configured as Portfast, it will cause the port to lose the Portfast status if a BPDU is received on it. This will force the port to participate in STP convergence. This is unlike the behavior seen with BPDUGuard where the port is put into an error disabled mode. BPDUFilter can be enabled on the switchport using the “spanning-tree bpdufilter enable” command.
UplinkFast
To understand how UplinkFast helps speed up the convergence, consider the network shown in Figure 6-10. SwitchA is the Root Bridge in the network.
Figure 6-10 UplinkFast
Now consider the following output from SwitchB
SwitchB#show spanning-tree vlan 5
VLAN0005
Spanning tree enabled protocol ieee
Root ID Priority 32773
Address 0013.c3e8.2500
Cost 19
Port 14 (FastEthernet0/14)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32773 (priority 32768 sys-id-ext 5)
Address 0017.94bd.1680
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa0/14 Root FWD 19 128.14 P2p
Fa0/15 Altn BLK 19 128.15 P2p
SwitchB#show spanning-tree uplinkfast
UplinkFast is disabled
We will use the following debug commands on the switch.
Spanning Tree event debugging is on
SwitchB#debug spanning-tree uplinkfast
Spanning Tree uplinkfast debugging is on
These debugs will show us STP events and uplink fast messages. Now let’s shut down port fa0/14 on SwitchB which is currently the root port as per output given above.
*Mar 2 22:14:30.504: STP: VLAN0005 new root port Fa0/15, cost 19
*Mar 2 22:14:30.504: STP: VLAN0005 Fa0/15 -> listening
*Mar 2 22:14:30.504: STP: UFAST: removing prev root port Fa0/14 VLAN0005 port-id 800E
*Mar 2 22:14:32.420: %LINK-5-CHANGED: Interface FastEthernet0/14, changed state to administratively down
*Mar 2 22:14:32.504: STP: VLAN0005 sent Topology Change Notice on Fa0/15
*Mar 2 22:14:33.420: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to down
*Mar 2 22:14:45.504: STP: VLAN0005 Fa0/15 -> learning
*Mar 2 22:15:00.504: STP: VLAN0005 Fa0/15 -> forwarding
Note the time taken for fa0/15 to transition to forwarding state is 30 seconds. This is faster than the expected 50 seconds because listening and learning time were short in this P2P link between switches and no other hosts/switches are connected here.
Let’s enable UplinkFast on SwitchB and repeat the process:
SwitchB(config)#spanning-tree uplinkfast
SwitchB#show spanning-tree vlan 5
–output truncated–
Uplinkfast enabled
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa0/14 Root FWD 3019 128.14 P2p
Fa0/15 Altn BLK 3019 128.15 P2p
SwitchB(config)#int fa0/14
SwitchB(config-if)#shutdown
*Mar 2 22:28:23.300: STP: VLAN0005 new root port Fa0/15, cost 3019
*Mar 2 22:28:23.300: STP FAST: UPLINKFAST: make_forwarding on VLAN0005 FastEthernet0/15 root port id new: 128.15 prev: 128.14
*Mar 2 22:28:23.300: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0005 FastEthernet0/15 moved to Forwarding (UplinkFast).
*Mar 2 22:28:23.300: STP: UFAST: removing prev root port Fa0/14 VLAN0005 port-id 800E
*Mar 2 22:28:25.216: %LINK-5-CHANGED: Interface FastEthernet0/14, changed state to administratively down
*Mar 2 22:28:25.300: STP: VLAN0005 sent Topology Change Notice on Fa0/15
*Mar 2 22:28:26.216: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to down
SwitchB(config-if)#do show spanning-tree vlan 5
— output truncated–
Uplinkfast enabled
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa0/15 Root FWD 3019 128.15 P2p
Note the time taken for fa0/15 to transition to forwarding is less than a second! From 30 seconds downtime to less than a second with UplinkFast enabled. Now that you have seen the difference it makes, let us define what exactly it does.
If a switch has multiple links towards the root bridge, then UplinkFast marks the redundant link as an Alternate Port and brings it up quickly in case the Root Port fails. This is possible because blocked ports keep listening for BDPUs.
Cisco recommends caution when using UplinkFast. You should enable it only on switches that have blocked ports.
BackboneFast
UplinkFast works by finding alternate ports for directly connected links. Similarly BackboneFast works on finding an alternate path when an indirect link to the root port goes down. To understand how BackboneFast works, consider the network shown in Figure 6-11. SwitchA is the Root Bridge here and Fa0/20 on SwitchD in the root port.
If SwitchC looses connection to SwitchA, it will advertise itself as the root bridge to SwitchD. SwitchD will compare previous known information with the new information and will learn that SwitchC has lost connection with SwitchA. Since the new BPDU states that a designated switch (SwitchC) is now the root bridge, this BDPU is known as inferior BDPU.
Eventually SwitchD will receive a BDPU from SwitchB stating the SwitchA is still the Root Bridge and SwitchD will now mark fa0/17 as the root port instead of fa0/20. This is because the information from SwitchB matches the exisiting information on SwitchD. BackboneFast ensure a quick failover as soon as the inferior BPDU is received. It saves roughly 20 seconds out of the 50 seconds of convergence time.
The spanning-tree backbonefast command can be used in the global configuration mode to enable BackBoneFast as shown below:
Switch(config)#spanning-tree backbonefast
Figure 6-11 BackboneFast
