Lesson 22 - Spanning-Tree Cisco Enhancements

My previous two posts hopefully shed some light on IEEE 802.1d protocol (yes, it is STP). There are two more things I would like to add to that picture. The first thing, deals with situations when the topology changes and how it affects the STP time of convergence. The convergence here, means the time it takes to recompute the STP tree in order to keep the loop free paths upon failure. The second thing, I'd like to bring up is the Cisco STP enhanced the STP operation to decrease the time of convergence compared to the industry standard STP.

Before we delve into the details though, I need to explain something about BPDU frames first. It is true that it is the root bridge that originates those frames and sends them out its designated ports ( downstream, every 2 seconds by default). It is also true, that all other switches (non-root bridges), propagate them downstream out of their designated ports. This way all switches receive the information as to which switch is the root bridge in the network and if it is still functional.

However, what I withheld in previous posts was the types of BPDU frames. There are three types of those:

• Configuration - the type of BPDU which the root bridge sends every 2 seconds, and other switches propagate those out of their Designated Ports (downstream).
• Topology Change Notification (TCN) - the type of BPDU that a switch will send if it detects the topology change (port going down, or TCN received). This BPDU is sent out the Root Port (upstream) towards the root bridge informing it, that the tree needs to be recomputed.
• Topology Change Acknowledgement (TCA) - the type of BPDU that is sent back to the sender of TCN BPDU, acknowledging the reception of the notification.

How do those BPDUs fit into the grand scheme of things?

The default timer of how long the entries are kept in the MAC address table is 300 seconds (5 minutes). This means, that if a host connected to a port of the switch does not speak for at least five minutes, its MAC address is removed from the CAM table. That is a way too long for the switch to re-learn computer's MAC addresses if the STP topology changes.

But why do those MAC entries have to change?

Please, consider the Pic. 1 below. By now, you should be able to tell which ports of the switches are going to learn the PC1 and PC2 MAC addresses. Go ahead, click the Pic. 1, and put down on a piece of paper the switch names and the ports that learn MAC addresses of the PC1 and PC2. That is going to be a good refresher of how switches learn MAC addresses dynamically.

Pic 1 - STP Topology.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

If your answers match mine below, that means that you have mastered the lessons on bridging/switching and STP.

SW1 CAM:
F0/1 - 0000.1111.1111
F0/2 - 0000.2222.2222

SW2 CAM:
F0/1 - 0000.2222.2222
F0/2 - no mac addresses learned since the port is NDP
F0/3 - 0000.1111.1111

SW3 CAM:
F0/1 - 0000.1111.1111
F0/2 - no mac addresses learned as PC1 communicates using SW1
F0/3 - 0000.2222.2222

SW4 CAM: 
F0/1 - no mac addresses learned as SW2's port F0/2 is NDP
F0/2 - 0000.1111.1111
F0/2 - 0000.2222.2222

Now, lets create a problem that causes the topology change in our network. Consider Pic. 2 which shows us why some ports must re-learn the MAC addresses of PC1 and PC2.

Pic. 2 - STP Network Problem

Icons designed by: Andrzej Szoblik - http://www.newo.pl

Given the situation, STP needs to recalculate topology since we lose active connections betweenSW1 and SW2. If it were not for the STP operation in such circumstances, it would take 5 minutes (300 seconds) for the switches to re-learn MAC addresses according to the situation presented in Pic. 3. The resulting topology diagram is depicted below.

Try to put down on the paper which MAC addresses should be learned on which ports of the respective switches after failure (Pic. 3).

Pic. 3 - Topology after losing the connection between SW1 and SW2.

Icons designed by: Andrzej Szoblik - http://www.newo.pl

SW1 CAM: 
F0/1 - down 
F0/2 - 0000.1111.1111
F0/2 - 0000.2222.2222

SW2 CAM: 
F0/1 - down 
F0/2 - 0000.2222.2222
F0/3 - 0000.1111.1111

SW3 CAM: 
F0/1 - no MAC addresses learned
F0/2 - 0000.1111.1111
F0/3 - 0000.2222.2222

SW4 CAM: 
F0/1 - 0000.1111.1111
F0/2 - 0000.2222.2222

In order to decrease the time of re-learning MAC addresses, upon failure SW1 is going to send TCN BPDU out its Root Port. Normally, the Configuration BPDU are sent out Designated Ports NOT the Root Port. But this failure prompts the switches to notify the root bridge about the topology change. That is why, they will send TCN BPDU out their Root Port. All switches, in the path of this TCN BPDU must send the TCA BPDU (acknowledgement) back to the sender and forward TCN BPDUtowards the root bridge. As soon as the root bridge has been notified about the topology change, it begins to send TCN BPDUs out its Designated Ports, so other switches in the network also get notified to give them a chance to flush MAC addresses, recompute the tree and re-learn the MAC addresses according to the new topology (Pic. 3). This reduces the time of convergence from 5 minutes to about 30 - 50 seconds time, depending on the nature of the change.

You might question that and say that the default timers used here (30-50 second delay) are still inappropriate for today's networks transmitting voice, video and data. And you are quite right saying so. The mechanism is still not good enough. But remember, that those timers were designed as SAFE values (not causing the loops) given the maximum diameter of network of seven switches (hops) between the root bridge and the bottom switches. Also, remember that STP was designed when there were no multimedia transmissions being sent across the switches. Is there a solution to those timers? Of course. You may change them manually but DO NOT DO THAT unless you are very experienced with STP operation. Another option is to use some proprietary features implemented in Cisco switches.

Cisco with their STP Enhancement are able to decrease this 30-50 second timers even further allowing video, voice and data co-exist in our layer 2 networks. Keep in mind, that these enhancement are Cisco proprietary STP add-ons: 

1. STP Portfast (now part of standard implementation as well).
2. STP Uplinkfast.
3. STP Backbonefast (this one is beyond the scope of this tutorial).

Let us see how the first two can change the behavior of our sample topology.

STP Portfast feature should be configured on all EDGE ports, i.e. the ones that connect devices that do not send BPDU frames and cannot create loops. These would be your computers, servers, printers etc. What STP Portfast does, it simply skips the LISTEN and LEARN states, going directly to FORWARD state if there was TCN announced or the port in question is just brought up. Think about it. It makes no sense to flush the MAC addresses on the ports that connect the computers directly, since the topology change is not going to affect them. In the topology presented in this tutorial (Pic. 1, 2, and 3), the topology change did not affect the ports F0/3 on both SW2 andSW3 where PC1 and PC2 are connected respectively. They are still connected where they were before the topology change and their addresses are mapped to the same ports as before the change. So, there is no point of flushing the MAC address table entries on SW2 port F0/3 and SW3port F0/3. These ports are the candidates for STP Portfast. Because STP Portfast-enabled ports go FORWARD almost immediately, it is highly recommended to use this feature on ports connected to computers in order to avoid problems of getting the IP address using DHCP services.

There are two ways of enabling STP Portfast feature.

Method 1
In the global configuration mode, type in this command:

SW1(config)#spanning-tree portfast default

All ports that are discovered as EDGE ports (more on that in my next post about Rapid STP), will have STP portfast enabled by default. You can check that using a detailed STP output regarding a port (here F0/1):

SW1#show spanning-tree interface f0/1 detail 

The output shows that STP  portfast has been enabled on this port (look at BPDU received = 0, candidate for portfast):

Pic. 4 - STP F0/1 Detailed Output.

Method 2 
Another method is to type in the following command directly on the chosen port:

SW1(config)#interface f0/1

SW1(config-if)#spanning-tree portfast

This way, we turn on STP Portfast unconditionally (whether port does or does not receive BPDUs).

The second STP enhancement is STP Uplinkfast. This one should be configured on all ACCESS switches (the leaf switches in our topology NOT distribution ones). The feature that is enabled in the global config mode, shortens the time it takes to transition NDP port into RP role upon losing the current Root Port.

In our topology, consider SW2 that has lost its Root Port (F0/1, Pic. 2). Normally, that is without STP Uplinkfast enabled, it would take 30 seconds for the F0/2 port to transition to an RP role. Keep in mind that F0/2 does not have go to blocking state since it keeps receiving superior BPDUs with the Root Bridge ID. Thus, only 30 seconds are required by default (LISTEN+LEARN states). With STP Uplinkfast enabled, Cisco guarantee that the transition of F0/2 to forwarding state (RP role) is going to happen in under 5 seconds.

The configuration of STP Uplinkfast is done in the global config mode as shown below:

SW1(config)#spanning-tree uplinkfast

Similar, in functionality, is STP Backbonefast that could be implemented on distribution switches. However, the details of this feature are beyond the scope of this tutorial.

In my next post, I'm going to briefly present Rapid Spanning-Tree Protocol (IEEE 802.1w) and how it differs from a regular STP (IEEE 802.1d).