Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Understanding Spanning Tree

   

< Back Contents Next >

Understanding Spanning Tree

  

 

What Is Spanning Tree and Why Use Spanning Tree?

  

 

Two Key Spanning-Tree Protocol Concepts

  

 

Four-Step STP Decision Sequence

  

 

Three Steps of Initial STP Convergence

  

 

Five STP States

  

 

Three STP Timers

  

 

Mastering the show spantree Command

  

 

Two Types of BPDUs

  

 

Topology Change Process

  

 

Using Spanning Tree in Real-World Networks

  

 

Deterministic Root Bridge Placement

  

 

All of This Per VLAN!

  

 

Exercises

Save to MyCKS

 
Cisco LAN Switching (CCIE Professional Development series)

From: Cisco LAN Switching (CCIE Professional Development series)
Author: Kennedy Clark; Kevin Hamilton
Publisher: Cisco Press (53)
More Information

6. Understanding Spanning Tree

The authors would like to thank Radia Perlman for graciously contributing her time to review the material in this chapter.

This chapter covers the following key topics:

  • What Is Spanning Tree and Why Use Spanning Tree—Briefly explains the purpose of the Spanning-Tree Protocol (STP). Explains why some form of loop-prevention protocol is required to prevent broadcast storms and bridge table corruption.

  • Four-Step STP Decision Sequence—Describes the process that the Spanning-Tree Protocol uses for all evaluations and calculations.

  • Initial STP Convergence—A detailed examination of the three steps that STP uses to initially converge on a loop-free active topology.

  • STP States—Explains the five STP states and how the algorithm progresses through each state.

  • STP Timers—Discusses the three configurable timers utilized by the Spanning-Tree Protocol.

  • The show spantree Command—Provides a detailed explanation of the fields contained in this powerful command. Several useful tips are discussed.

  • BPDUs—Provides a detailed discussion of the frames used by bridges and switches to convey STP information. Decodes of actual BPDUs are explained.

  • Topology Change Process—Explains how the Topology Change process allows the network to reconverge more quickly after changes in the physical network.

  • Setting the Root Bridge—Explains how to manually place Root Bridges in your network for improved stability and performance.

  • Per VLAN Spanning Tree—Explains how Cisco supports one instance of the Spanning-Tree Protocol per VLAN. This features allows for extremely flexible designs and is detailed in Chapter 7, “Advanced Spanning Tree.”

Most network administrators and designers underestimate the importance of the Spanning-Tree Protocol (STP). As routers became popular in the early 1990s, STP faded into the background as a “less important protocol that just worked.” However, with the recent rise of switching technology, Spanning Tree has once again become an important factor that can have a tremendous impact on your network's performance.

In fact, STP often accounts for more than 50 percent of the configuration, troubleshooting, and maintenance headaches in real-world campus networks (especially if they are poorly designed). When I first encountered switching technology, I had the typical “I'm a Layer 3 pro, how hard could this STP stuff be?” mentality. However, I soon learned that STP is a complex protocol that is generally very poorly understood. I found it difficult to locate good Spanning Tree information, especially information about modern implementations of STP. The goal of this chapter (and Chapter 7) is to make your STP journey smooth sailing.

This chapter covers the mechanics of the Spanning-Tree Protocol as it performs its basic loop-prevention duties. To build a baseline knowledge of STP, the chapter begins by answering the questions “What is Spanning Tree?” and “Why do I need Spanning Tree?” From there, the chapter walks through the Spanning Tree algorithm in detail. In short, this chapter sets the stage for Chapter 7, “Advanced Spanning Tree,” where complex topics such as load balancing and minimizing convergence time are presented in detail.

This chapter uses the terms bridge, switch, and Layer 2 switch interchangeably. Although some argue that there are differences between these types of devices, these differences are irrelevant when discussing Spanning Tree. This is particularly true when discussing the STP standards that were written prior to the development of hardware-based switches. For example, you will learn about the Root Bridge concept (don't worry about what it means yet). Although the term Root Switch is becoming more common, I find it awkward when first learning how the Spanning-Tree Protocol functions. However, the term switch is used when discussing particular network designs and deployments because it is rare to deploy a traditional, software-based bridge today.

CAUTION

Please note that the examples used in this chapter (and Chapter 7) are designed to illustrate the operation of the Spanning-Tree Protocol, not necessarily good design practices. Design issues are addressed in Chapter 11, “Layer 3 Switching,” Chapter 14, “Campus Design Models,” Chapter 15, “Campus Design Implementation,” and Chapter 17, “Case Studies: Implementing Switches.”

What Is Spanning Tree and Why Use Spanning Tree?

In its most basic sense, the Spanning-Tree Protocol (STP) is a loop-prevention protocol. It is a technology that allows bridges to communicate with each other to discover physical loops in the network. The protocol then specifies an algorithm that bridges can use to create a loop-free logical topology. In other words, STP creates a tree structure of loop-free leaves and branches that spans the entire Layer 2 network. The actual mechanics of how the bridges communicate and how the STP algorithm works is the subject of the rest of the chapter.

Loops occur in networks for a variety of reasons. The most common reason you find loops in networks is the result of a deliberate attempt to provide redundancy—in case one link or switch fails, another link or switch can take over. However, loops can also occur by mistake (of course, that would never happen to you). Figure 6-1 shows a typical switch network and how loops can be intentionally used to provide redundancy.

Figure 6-1. Networks Often Include Bridging Loops to Provide Redundancy

The catch is that loops are potentially disastrous in a bridged network for two primary reasons: broadcast loops and bridge table corruption.

Broadcast Loops

Broadcasts and Layer 2 loops can be a dangerous combination. Consider Figure 6-2.

Figure 6-2. Without STP, Broadcasts Create Feedback Loops

Assume that neither switch is running STP. Host-A begins by sending out a frame to the broadcast MAC address (FF-FF-FF-FF-FF-FF) in Step 1. Because Ethernet is a bus medium, this frame travels to both Cat-1 and Cat-2 (Step 2).

When the frame arrives at Cat-1:Port-1/1, Cat-1 will follow the standard bridging algorithm discussed in Chapter 3, “Bridging Technologies,” and flood the frame out Port 1/2 (Step 3). Again, this frame will travel to all nodes on the lower Ethernet segment, including Cat-2:Port1/2 (Step 4). Cat-2 will flood the broadcast frame out Port 1/1 (Step 5) and, once again, the frame will show up at Cat-1:Port-1/1 (Step 6). Cat-1, being a good little switch, will follow orders and send the frame out Port 1/2 for the second time (Step 7). By now I think you can see the pattern—there is a pretty good loop going on here.

Additionally, notice that Figure 6-2 quietly ignored the broadcast that arrived at Cat-2:Port-1/1 back in Step 2. This frame would have also been flooded onto the bottom Ethernet segment and created a loop in the reverse direction. In other words, don't forget that this “feedback” loop would occur in both directions.

Notice an important conclusion that can be drawn from Figure 6-2—bridging loops are much more dangerous than routing loops. To understand this, refer back to the discussion of Ethernet frame formats in Chapter 1, “Desktop Technologies.” For example, Figure 6-3 illustrates the layout of a DIX V2 Ethernet frame.

Figure 6-3. DIX Version 2 Ethernet Frame Format

Notice that the DIX V2 Ethernet frame only contains two MAC addresses, a Type field, and a CRC (plus the next layer as Data). By way of contrast, an IP header contains a time to live (TTL) field that gets set by the original host and is then decremented at every router. By discarding packets that reach TTL=0, this allows routers to prevent “run-away” datagrams. Unlike IP, Ethernet (or, for that matter, any other common data link implementation) doesn't have a TTL field. Therefore, after a frame starts to loop in the network above, it continues forever until one of the following happens:

  • Someone shuts off one of the bridges or breaks a link.

  • The sun novas.

As if that is not frightening enough, networks that are more complex than the one illustrated in Figure 6-2 (such as Figure 6-1) can actually cause the feedback loop to grow at an exponential rate! As each frame is flooded out multiple switch ports, the total number of frames multiplies quickly. I have witnessed a single ARP filling two OC-12 ATM links for 45 minutes (for non-ATM wizards, each OC-12 sends 622 Mbps in each direction; this is a total of 2.4 Gbps of traffic)! For those who have a hard time recognizing the obvious, this is bad.

As a final note, consider the impact of this broadcast storm on the poor users of Host-A and Host-B in Figure 6-2. Not only can these users not play Doom (a popular game on campus networks) with each other, they can't do anything (other than go home for the day)! Recall in Chapter 2, “Segmenting LANs,” that broadcasts must be processed by the CPU in all devices on the segment. In this case, both PCs lock up trying to process the broadcast storm that has been created. Even the mouse cursor freezes on most PCs that connect to this network. If you disconnect one of the hosts from the LAN, it generally returns to normal operation. However, as soon as you reconnect it to the LAN, the broadcasts again consume 100 percent of the CPU. If you have never witnessed this, some night when only your worst enemy is still using the network, feel free to create a physical loop in some VLAN (VLAN 2, for example) and then type set spantree 2 disable into your Catalyst 4000s, 5000s, and 6000s to test this theory. Of course, don't do this if your worst enemy is your boss!

Bridge Table Corruption

Many switch/bridge administrators are aware of the basic problem of broadcast storms as discussed in the previous section. However, fewer people are aware of the fact that even unicast frames can circulate forever in a network that contains loops. Figure 6-4 illustrates this point.

Figure 6-4. Without STP, Even Unicast Frames Can Loop and Corrupt Bridging Tables

For example, suppose that Host-A, possessing a prior ARP entry for Host-B, wants to send a unicast Ping packet to Host-B. However, Host-B has been temporarily removed from the network, and the corresponding bridge-table entries in the switches have been flushed for Host-B. Assume that both switches are not running STP. As with the previous example, the frame travels to Port 1/1 on both switches (Step 2), but the text only considers things from Cat-1's point of view. Because Host-C is down, Cat-1 does not have an entry for the MAC address CC-CC-CC-CC-CC-CC in its bridging table, and it floods the frame (Step 3). In Step 4, Cat-2 receives the frame on Port 1/2. Two things (both bad) happen at this point:

  1. Cat-2 floods the frame because it has never learned MAC address CC-CC-CC-CC-CC-CC (Step 5). This creates a feedback loop and brings down the network.

  2. Cat-2 notices that it just received a frame on Port 1/2 with a source MAC of AA-AA-AA-AA-AA-AA. It changes its bridging entry for Host-A's MAC address to the wrong port!

As frames loop in the reverse direction (recall that the feedback loop exists in both directions), you actually see Host-A's MAC address flipping between Port 1/1 and Port 1/2.

In short, not only does this permanently saturate the network with the unicast ping packet, but it corrupts the bridging tables. Remember that it's not just broadcasts that can ruin your network.

   

< Back Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.