In this Daily Feature, we’ll look at some issues that may cause STP to malfunction and what we can do about them. In a spanning tree environment, we’ll assume that redundant links are employed. The troubles generally arise when spanning tree is unable to block a redundant link and a bridging loop occurs. Such a loop is usually responsible for a broadcast storm, which can easily be detected with a protocol analyzer. We can also take a look at the state of the spanning tree at any point in time. Another thought would be to check the traffic and utilization on your switches.

Hardware type

Note: The following command examples are based on the CatOS, version 5.x, utilized in the 4000, 5000, and 6000 series Cisco switches.

What is STP doing?
To get an idea of what STP is doing on your network, you can use the following command to get a glimpse of ports that are blocking and forwarding:
show spantree summary

The output of this command is a tabular listing of the ports involved and their current states. To look at switch port information, you can use the show port command. To get a good picture of the problem, you’ll want to check suspect ports on more than one switch.
show port

By viewing the output of this command, you can start to piece together the puzzle that is causing your network to loop. You can use the aforementioned form of the command for a list of all ports or you can specify module and port numbers to get more detailed statistics on specific ports. Things to look for in the output of this command are signs that blocked ports are receiving Bridge Protocol Data Units (BPDUs). This command has several options that you may want to explore for further detail.

Additionally, you can use the show mac command to view information about all packets received and sent on a port:
show mac module#/port#

Another command that will give you a comprehensive look at the switch backplane usage is the show system command:
show system

The benefit of this command is that it shows you the current usage, as well as peak usage. Look for extreme peaks that may identify potential loops.

One thing to always consider when interconnecting network devices is the fallibility of the auto-negotiation process. Auto-negotiation allows devices capable of varying speeds to agree to operate at a common speed. Most vendors of networking devices will warn of interoperability issues that can occur when you attempt to connect their products with those of other vendors. However, what they fail to mention is that oftentimes, auto-negotiation does not work that well between two of their own devices. Additionally, if two devices are operating with different duplex settings, you’re going to have trouble. This problem may manifest itself as collisions on an interface that should not experience collisions. To check this, simply identify the ports on both switches at either end of a link. You can then use the show port command on both devices to look for a duplex mismatch. This is especially relevant in the Cisco environment with several different switch types sporting different port capabilities and differing OS software.

Setting ports
To avoid this problem, I suggest that you explicitly set the ports at both ends of an inter-switch link to the same configuration using the set port command:
set port duplex mod#/port# half | full
set port speed mod#/port# {10 |100 |auto}

Also, something to keep in mind at the access level switches is the delay time that STP can impose when a workstation is first started. If it does not negotiate a forwarding state on an access port before the workstation completes its startup sequence, the PC may not be able to log in properly. In a NetWare environment, you may not get a client32 login prompt. With Windows NT, you may get a message that no domain server was available. A good way to avoid this is to set all switch access ports to portfast mode so that they immediately begin forwarding, as follows:
set spantree portfast module#/port#

Another command that Cisco has implemented in later CatOS versions is port host, described as follows:
set port host module#/port#

This command actually adds two statements to your config file. It sets spanning tree to portfast mode for the port range specified, as well as setting port channeling off for the same port range. You’ll want to exercise caution using portfast mode. On the one hand, it is a great benefit to transition access ports to a forwarding state immediately so that the workstation can access network resources properly at startup. However, abuse of portfast is a fairly common reason for STP problems. Be sure that you don’t set any of your trunk ports for portfast mode, as they will not participate properly in the STP process and will most likely cause a loop to occur.

Through careful configuration and a firm grasp of the show commands available, we can troubleshoot and resolve spanning tree issues in short order. In my next article in this series on STP, I’ll explore some design issues that will help build a more robust spanning tree environment and avoid the pitfalls that can cause bridging loops to jam the network.

Editorial disclaimer

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.