Network Basics: Spanning Tree Protocol

For new networkers, Spanning Tree Protocol (STP) can be an intimidating topic. Many old-timers speak of spanning-tree in ominous tones, recounting the time when a “spanning-tree loop” brought down the network. Some managers strictly forbid anyone from changing anything related to the spanning tree, fearing a resulting service interruption. Some of the fear surrounding spanning trees is likely based on bad experiences, but some are based on ignorance—at least partly. We tend to fear what we don’t understand.

What is spanning tree protocol?

It’s impossible for one blog post to entirely dispel the fear you might have surrounding a spanning tree. That said, the key to putting your trepidation behind you begins with understanding the spanning tree protocol’s purpose. First and foremost, spanning tree is a loop prevention protocol. Spanning tree does not, in and of itself, cause loops. While it can be argued in extreme cases that spanning tree fails to prevent a loop from occurring, it certainly doesn’t cause them either.

Why all this focus on loops?

In a network, a loop provides a never-ending path for network traffic to follow. In Ethernet, frames never die; there’s no time to live function attached to a traditional Ethernet frame. Therefore, if a loop exists, frames with no explicit destination (like broadcast frames) circle around the network forever. As broadcast frames accumulate, the negative impact on the network increases. Broadcast frames are meant for everyone on the segment; every attached host must process the broadcast. Over and over again. In increasing volume over time. For this reason, bridging loops are sometimes called broadcast storms.

These storms impact network utilization and take up CPU resources. Network switches and routers are heavily impacted by these storms; their CPUs spike to 100% utilization in seconds due to all the broadcast processing they must handle. This often prevents them from doing other things they should be doing, like maintaining the spanning-tree topology or keeping up with their routing neighbors. The end result is a network outage.

Understanding spanning tree protocol

The spanning tree’s job is to prevent the bridging loops that cause network chaos. The simplest way to explain how the spanning tree does this is by way of an example. Consider the following simple diagram, showing three switches configured in a triangle.

In this diagram, we’ve created a loop. So, how does the spanning-tree prevent this loop from causing network problems? The spanning-tree will block a link in the topology so that it can no longer be used to forward traffic. While the physical cable is still plugged in, the spanning tree tells the switch not to use the link anymore. Thus, the loop is mitigated.

No doubt you’re wondering how spanning-tree decides which link is the right one to block. To answer that, you need to understand a few spanning-tree basics.

1. Switches share spanning-tree information with each other using bridge protocol data units (BPDUs). The terms “switch” and “bridge” are, for our purposes, interchangeable.
2. Spanning tree switches elect one of the bridges in the domain to be the root bridge. In our diagram above, switches 1, 2, and 3 have had an election to determine which of them should be the root.
3. When a root is decided, all switches calculate the lowest cost path back to the root bridge. More costly paths are blocked.

Let’s look at this in more detail. In the diagram below, we assume switch 1 has become the root bridge. Switch 2 can get to switch 1 in two ways: directly or via switch 3. The direct path has a cost of 10. The path via switch 3 has a cost of 20. The more costly link is blocked.

Now, you might be wondering how spanning-tree bridges elect a root bridge. It’s mostly media spending and campaigning relentlessly. Just kidding. All spanning-tree switches are assigned a bridge ID containing a numerical bridge priority and a MAC address uniquely identifying the switch. The switch with the lowest bridge ID wins the election. This usually translates to the lowest bridge priority winning, but if multiple switches have the same bridge priority, the lowest MAC address embedded in the bridge ID serves as the tiebreaker.

Maintaining control of your spanning tree

Here are some recommendations for establishing and maintaining control of a spanning tree design:

1. Choose the root bridge yourself by setting bridge priorities. If you know your network topology well, the choice of root bridge should be intuitive. In most network designs, a switch or pair of switches serves as the network’s topological center. They are often called “core” switches. Generally speaking, cores are good choices as root bridges. In a dual-core design on networks containing many VLANs, a common strategy is to make one core the root bridge for odd-numbered VLANs, and the other core the root bridge for even-numbered VLANs. This assumes you’re running “per VLAN spanning tree,” the default in Cisco environments. This even-odd scheme allows for some load-balancing of traffic between the dual cores. If you don’t set bridge priorities yourself, you’ll find that all switches have the same root bridge priority by default: 32768. Since the lowest MAC address is the only needed tiebreaker, any switch in the topology could become the root bridge—even a lowly, ancient closet switch quietly running in a dusty corner of your network. Therefore, setting the root bridge yourself is wise, as you should end up with a traffic forwarding path that makes sense for your network. In Cisco networks, a switch’s bridge priority is set in increments of 4096 using the “spanning-tree VLAN X priority” command, where X is the VLAN number or range of VLANs for which you wish to set priority.

2.Guard the root bridge. Be sure no other switches take over the root role.

• Keep rogue switches off the network. A simple way to do this is with BPDU guard, which we discussed in a previous blog post. BPDU guard is a first line of defense against a switch being unexpectedly introduced into the spanning-tree domain.
• Keep would-be usurpers to the root bridge thrown outside the gates. Cisco switches offer a feature called root guard, which places a port into a blocking “root-inconsistent” state if a superior BPDU (a BPDU announcing a bridge with a lower ID) arrives. The root guard is configured on interfaces where a root bridge is never expected to appear. While you might think root guard can go just about anywhere, think it through first. Many networks are configured not only with an explicit root bridge (the one with the lowest bridge ID) but also an explicit backup bridge to take over duties of the root if the main root bridge goes down. A root guard should never be installed on an interface where the root bridge might legitimately appear at some point. This will vary widely depending on your network topology, but a general guideline is to think of a root guard as a perimeter defense mechanism. Placing root guards at the network edge is usually safe. Placing root guards on certain interfaces that interconnect switches can and should be done, but determining which ones require more careful planning. To apply root guard to a Cisco switch interface, use the command “spanning-tree guard root.”

3. Avoid unexpected loops due to failed cabling. The last spanning-tree guard we’ll discuss here is loop guard. The spanning-tree loop guard has a very specific purpose: to prevent a bridging loop that could be caused by one-way traffic, preventing the spanning tree from hearing all the BPDUs it should. One-way traffic is admittedly rare in networking but happens most commonly on fiber-optic links where one fiber in a send/receive pair fails. When a loop guard is enabled on an interface, it works by listening for BPDUs coming from the neighboring switch. If no BPDUs are received, the loop guard assumes something has gone wrong and blocks the port by placing it into a “loop-inconsistent” state. When BPDUs are received again, the port is allowed to forward traffic. On Cisco switches, a loop guard is enabled with the “spanning-tree guard loop” interface command. As with the root guard, the correct placement of the loop guard will vary by network topology and should be applied only after careful consideration.

Want to learn more about spanning tree protocol?

This blog post has only just introduced the spanning tree. The careful networker who’s new to Ethernet effective switching and spanning tree configuration should see the topics addressed here as a jumping-off point for more learning. A good place to start is by exploring your own network spanning-tree topology. Figure out which switch is the root bridge, which interfaces are blocked, what flavor of spanning tree is running, and if the spanning-tree topology changes per VLAN. Create a diagram. Does the spanning-tree design appear optimal? If not, what changes would improve it and why?

Cisco provides a number of outstanding documents that can help you answer these questions, learn more about spanning trees, and apply an appropriate design for your environment. Here are some of my favorites, including some interesting topics we didn’t have time to discuss here.

• Understanding and Configuring Spanning-Tree Protocol (STP) on Catalyst Switches
• Understanding Rapid Spanning-Tree Protocol (802.1w)
• Understanding Multiple Spanning-Tree Protocol (802.1s)
• Spanning-Tree Protocol Enhancements using Loop Guard and BPDU Skew Detection Features
• Spanning-Tree Protocol Root Guard Enhancement