5 Prevalent Spanning Tree Mistakes and How to Avoid Them

Spanning Tree Protocol has been a fundamental part of most computer networks since the early 1990’s. The original IEEE 802.1D flavor of Spanning Tree Protocol was created by Radia Perlman back in 1985 as a means to block loops in the physical layer 2 Ethernet topology in order to prevent broadcast storms, mac table instability and multiple frame transmission problems.

In fulfilling its intended purpose, Spanning Tree generally works straight out of the box with little or no tweaking. It elects a root bridge, calculates best paths to the root from the other switches, and blocks any suboptimal links that would create a loop.

One would think that because of its long stint as a staple in networking, Spanning Tree configurations at most companies would be thoroughly dialed in and configured for max efficiency. However, we have not found this to be the case.

Because no manual configuration is initially required for a basic level of performance, often no further adjustments are made to the STP configuration. When optimization is not initially neglected, it is often later neglected as the network changes leaving a once-optimized Spanning Tree behind. At some point down the line many businesses encounter problems that could have been avoided by paying a little more attention to this often uncared for behind-the-scenes protocol.

Basic implementation and configuration mistakes seem to be quite common, especially with small to mid-sized businesses. Some of these mistakes we see over and over again, despite the fact that they could be easily dodged. Below is a summary of the 5 most common mistakes we find and how to avoid or resolve them.

1.) Failure to Utilize 802.1W Rapid-PVST

These days most switches are capable of running the faster, more recent version of STP, called Rapid Spanning Tree. However, it is surprising how many businesses are still configured to use the much slower 802.1D standard, which is now well over 2 decades old! I’m hard pressed to think of many items in technology that are not in the graveyard long before reaching that kind of life-expectancy. But more important than age is speed.

The initial standard, which we so commonly see still being unnecessarily utilized, often takes around 50 seconds to converge (20 sec hold, 2 x 15 sec forward timers). In today’s fast-paced networks, that is an eternity! Utilizing Rapid Spanning Tree can make your layer 2 convergence more than 10x faster, and with a little extra tuning even faster than that.

Aside from drastically increased convergence, core functionality remains that same, with some changes in the timers and the way that RSPT moves from Discarding to Forwarding. Configuration is painless and straight forward with backwards compatibility in the event that the network requires fallback to 802.1D. This is a no-brainer!

2.) Root Bridge Not Manually Configured

If you never change the STP priority on your switches, the switch with the lowest mac-address on your network can end up as the root switch. Oftentimes, older, much less powerful switches will have lower mac-addresses. If one of these switches becomes the root it can cause big problems for any connected LAN segments.

Typically you want one of your more robust switches, located in a focal point of your topology, such as the core, to be designated as root. This is unlikely to happen by chance, so it is recommended that you configure the root switch and backup root by design, utilizing the Cisco command “spanning-tree vlan # root primary|secondary” or “spanning-tree vlan # priority #” (lower priority wins).

There are also cases where the location of root should mirror other factors in topology such as coinciding with the frame-relay hub or the FHRP Master/Active layer 3 switch. Failure to take these design considerations into account usually leads to suboptimal data paths and associated traffic congestion.

3.) Multiple Uplinks Not Correctly Aggregated

Believe it or not, we have repetitively witnessed the following spoiled fruit from the labor of various well-meaning support technicians. The technician connects multiple ports from one switch to the other for uplink, expecting to be able to utilize the bandwidth from the multiple connections, only to have Spanning Tree rain on the parade by allowing connectivity only through a single link.

We must not forget that it is STP’s job to block redundant links in an effort to keep the network loop free. The links introduced by the technician in an attempt to gain uplink bandwidth/redundancy would cause a L2 loop if Spanning Tree was not there to block all but one of them, so that is exactly what it does. Only one of the cables will actually carry traffic, unless further action is taken. Remember that in order to utilize redundant links in an uplink, they must be correctly configured for control plane aggregation.

Etherchannel would be one common method of accomplishing this. It is readily available for configuration on most platforms through protocols such as (LACP and PAgP). This method logically bundles the links together in the control plane, and treats them as a single interface eliminating any looping and allowing full utilization of the aggregated bandwidth (at least for links numbered in powers of 2). Other methods could include Multi-Chassis Etherchannel and other virtual switch technologies.

4.) STP Security Not Implemented

There are also security considerations that should be taken into consideration with all version of Spanning Tree. Unfortunately, this is something that is often overlooked entirely on many of the networks we’ve seen.

For instance, Portfast is often configured on edge ports going out to end user devices to speed up convergence by not going through unnecessary transitory states when no other switch is expected on that port. Portfast effectively disables the listening/learning STP states for that port.

Since the port may be publicly accessible, it is conceivable that another switch could be plugged into the port, possibly even with malicious intent. Since Portfast enabled ports do not go through protective transitional states, loop prevention could be bypassed and a denial of service attach could ensue.

To avoid having an unauthorized switch become root, create a loop or initiate a DOS attack, simply make sure that BPDU guard is enabled on any port that is running Portfast. These two belong side by side. BPDU guard will listen for a Bridge Protocol Data Unit on the link, and if a BPDU comes across it will take action to shut the port down, thus defending the network.

Root Guard and Etherchannel Guard are other features that can be used to make sure that your STP configuration remains secure and functioning as desired.

5.) STP Not Scaled to Efficient Design Standards

As a network evolves, it should be evaluated on a regular basis. One of the things that is important to check is the LAN size in relation to spanning-tree function. Like a human adolescent, networks often grow in spurts. Sometimes switches are installed in a rush to fill time-sensitive capacity needs, and the LAN segment can sneakily end up growing beyond the size at which Spanning Tree can function optimally.

For instance, 802.1D recommends that STP include no more than 7 switch hops. However, it is easy to surpass this count if switches are allowed to be daisy-chained out on the fly to extend areas of the network which are experiencing fast growth. LAN’s should be evaluated on a regular basis to determine if further segmentation may be necessary in order to bring STP back within optimal design standards.

Why Does It Matter?

The above items have been found over and over again in various networks that we have assessed. Each of the issues has a relatively simple and straight forward fix. Making sure that these common mistakes are not found in your network can alleviate a lot of headaches by noticeably increasing reliability, performance and convergence. It is recommended that you avoid these issues in the first place if you can, or implement the corrections ASAP. It will be well worth while!

written by Josh R Blaylock, Network Engineer – IT Solution Ramp