Chapter 8. Spanning Tree Protocol Concepts

This chapter covers the following exam topics:

2.0. Basic data center networking concepts

2.3. Describe switching concepts and perform basic configuration

2.3.a. STP

Spanning Tree Protocol (STP) allows Ethernet LANs to have the added benefit of redundant links while overcoming the known problems that occur when those extra links are added. Redundant links in a LAN design allow the LAN to keep working even when some links fail or even when entire switches fail. Proper LAN design should add enough redundancy so that no single point of failure crashes the LAN; STP allows the design to use redundancy without causing some other problems.

This chapter discusses the concepts behind STP. In particular, it discusses why LANs need STP, what STP does to solve certain problems in LANs with redundant links, and how STP does its work.

This chapter breaks the STP discussions into three major sections. The first examines the oldest version of STP as defined by the IEEE, based on the 802.1D standard, and is generally referred to as STP. The second major section looks at various improvements to 802.1D STP over the years, including Port-Channel and PortFast.

1. Which of the following IEEE 802.1D port states are stable states used when STP has completed convergence? (Choose three answers.)

a. Blocking

b. Forwarding

c. Listening

d. Learning

e. Discarding

2. Which of the following are transitory IEEE 802.1D port states used only during the process of STP convergence? (Choose two answers.)

a. Blocking

b. Forwarding

c. Listening

d. Learning

e. Discarding

3. Which of the following bridge IDs win election as root, assuming that the switches with these bridge IDs are in the same network?

a. 32769:0200.1111.1111

b. 32769:0200.2222.2222

c. 4097:0200.1111.1111

d. 4097:0200.2222.2222

e. 40961:0200.1111.1111

4. Which of the following facts determines how often a nonroot switch sends an 802.1D STP hello BPDU message?

a. The hello timer as configured on that switch.

b. The hello timer as configured on the root switch.

c. It is always every 2 seconds.

d. The switch reacts to BPDUs received from the root switch by sending another BPDU 2 seconds after receiving the root BPDU.

5. What STP feature causes an interface to be placed in the forwarding state as soon as the interface is physically active?

a. STP

b. Port-Channel

c. Root Guard

d. PortFast

6. Switch S1 sits in a LAN that uses RSTP. SW1’s E1/1 port is its root port, with E1/2 as the only other port connected to other switches. SW1 knows that it will use E1/2 as its root port if E1/1 fails. If SW1’s E1/1 interface fails, which of the following is true?

a. SW1 waits 10 times the hello timer (default 10 × 2 = 20 seconds) before reacting.

b. SW1 waits three times the hello timer (default 3 × 2 = 6 seconds) before reacting.

c. SW1 does not wait but makes E1/2 the root port and puts it in a learning state.

d. SW1 does not wait but makes E1/2 the root port and puts it in a forwarding state.

7. Switch SW1 sits in a LAN that uses RSTP. SW1 has 24 RSTP edge ports and is also receiving hello BPDUs on two point-to-point ports, E1/1 and E1/2. SW1 chooses E1/1 as its root port. Which of the following about the RSTP port role of E1/2 is true?

a. Backup role

b. Blocking role

c. Discarding role

d. Alternate role

Historically, Spanning Tree Protocol (STP) was the first loop-prevention mechanism for Ethernet networks that used bridges and later switches. With STP enabled, some switches block ports so that these ports do not forward frames. In effect, the LAN can have redundant links for backup purposes, but STP logically stops using some links to remove the loops from the network.

STP intelligently chooses which ports to block, with two goals in mind:

All devices in a VLAN can send frames to all other devices. In other words, STP does not block too many ports, cutting off some parts of the LAN from other parts.

Frames have a short life and do not loop around the network indefinitely.

STP strikes a balance, allowing frames to be delivered to each device, without causing the problems that occur when frames loop through the network over and over again.

STP prevents looping frames by adding an additional check on each interface before a switch uses it to send or receive user traffic. That check works like this: If the port is in STP forwarding state in that VLAN, use it as normal; if it is in STP blocking state, however, block all user traffic and do not send or receive user traffic on that interface in that VLAN.

Note that these STP states do not change the other information you already know about switch interfaces. The interface’s state of connected/notconnect does not change. The interface’s operational state as either an access or trunk port does not change. STP adds this additional STP state, with the blocking state basically disabling the interface.

In many ways, those last two paragraphs sum up what STP does. However, the details of how STP does its work can take a fair amount of study and practice. This first major section of the chapter begins by explaining the need for STP and the basic ideas of what STP does to solve the problem of looping frames. The majority of this section looks at how STP goes about choosing which switch ports to block to accomplish its goals.

Just one frame that loops around a network causes what is called a broadcast storm. Broadcast storms happen when broadcast frames, multicast frames, or unknown-destination unicast frames loop around a LAN indefinitely. Broadcast storms can saturate all the links with copies of that one single frame, crowding out good frames, as well as significantly impacting end-user PC performance by making the PCs process too many broadcast frames.

To help you understand how this occurs, Figure 8-1 shows a sample network in which Bob sends a broadcast frame. The dashed lines show how the switches forward the frame when STP does not exist.

Remember the LAN switching logic from back in Chapter 3, “Fundamentals of Ethernet LANs”? That logic tells switches to flood broadcasts out all interfaces in the same VLAN except the interface in which the frame arrived. In the figure, that means SW3 forwards Bob’s frame to SW2, SW2 forwards the frame to SW1, SW1 forwards the frame back to SW3, and SW3 forwards it back to SW2 again.

When broadcast storms happen, frames like the one in Figure 8-1 keep looping until something changes—someone shuts down an interface, reloads a switch, or does something else to break the loop. Also note that the same event happens in the opposite direction. When Bob sends the original frame, SW3 also forwards a copy to SW1, SW1 forwards it to SW2, and so on.

Looping frames also cause a MAC table instability problem. MAC table instability means that the switches’ MAC address tables keep changing the information listed for the source MAC address of the looping frame. For example, SW3 begins Figure 8-1 with a MAC table entry for Bob, at the bottom of the figure, as follows:

0200.3333.3333 Fa0/13 VLAN 1

However, now think about the switch-learning process that occurs when the looping frame goes to SW2, then SW1, and then back into SW3’s Gi0/1 interface. SW3 thinks, “Hmm... the source MAC address is 0200.3333.3333, and it came in my Gi0/1 interface. Update my MAC table!” This results in the following entry on SW3:

0200.3333.3333 Gi0/1 VLAN 1

At this point, SW3 itself cannot correctly deliver frames to Bob’s MAC address. At that instant, if a frame arrives at SW3 destined for Bob—a different frame than the looping frame that causes the problems—SW3 incorrectly forwards the frame out Gi0/1 to SW1.

The looping frames also cause a third problem: Multiple copies of the frame arrive at the destination. Consider a case in which Bob sends a frame to Larry but none of the switches know Larry’s MAC address. Switches flood frames sent to unknown destination unicast MAC addresses. When Bob sends the frame destined for Larry’s MAC address, SW3 sends a copy to both SW1 and SW2. SW1 and SW2 also flood the frame, causing copies of the frame to loop. SW1 also sends a copy of each frame out Fa0/11 to Larry. As a result, Larry gets multiple copies of the frame, which may result in an application failure, if not more pervasive networking problems.

Table 8-2 summarizes the main three classes of problems that occur when STP is not used in a LAN with redundancy.

Figure 8-2 shows a simple STP tree that solves the problem shown in Figure 8-1 by placing one port on SW3 in the blocking state.

Now when Bob sends a broadcast frame, the frame does not loop. As shown in the steps in the figure:

Step 1. Bob sends the frame to SW3.

Step 2. SW3 forwards the frame only to SW1, but not out Gi0/2 to SW2, because SW3’s Gi0/2 interface is in a blocking state.

Step 3. SW1 floods the frame out both Fa0/11 and Gi0/1.

Step 4. SW2 floods the frame out Fa0/12 and Gi0/1.

Step 5. SW3 physically receives the frame, but it ignores the frame received from SW2 because SW3’s Gi0/2 interface is in a blocking state.

With the STP topology in Figure 8-2, the switches simply do not use the link between SW2 and SW3 for traffic in this VLAN, which is the minor negative side effect of STP. However, if either of the other two links fails, STP converges so that SW3 forwards instead of blocks on its Gi0/2 interface.

That completes the description of what STP does, placing each port into either a forwarding or blocking state. The more interesting question, and the one that takes a lot more work to understand, is the question of how and why STP makes its choices. How does STP manage to make switches block or forward on each interface? And how does it converge to change state from blocking to forwarding to take advantage of redundant links in response to network outages? The following sections answer these questions.

The process used by STP, sometimes called the spanning-tree algorithm (STA), chooses the interfaces that should be placed into a forwarding state. For any interfaces not chosen to be in a forwarding state, STP places the interfaces in blocking state. In other words, STP simply picks which interfaces should forward, and any interfaces left over go to a blocking state.

STP uses three criteria to choose whether to put an interface in forwarding state:

STP elects a root switch. STP puts all working interfaces on the root switch in forwarding state.

Each nonroot switch considers one of its ports to have the least administrative cost between itself and the root switch. The cost is called that switch’s root cost. STP places its port that is part of the least-root-cost path, called that switch’s root port (RP), in forwarding state.

Many switches can attach to the same Ethernet segment, but in modern networks, normally two switches connect to each link. The switch with the lowest root cost, as compared with the other switches attached to the same link, is placed in forwarding state. That switch is the designated switch, and that switch’s interface, attached to that segment, is called the designated port (DP) .

All other interfaces are placed in a blocking state. Table 8-3 summarizes the reasons STP places a port in forwarding or blocking state.

The STP bridge ID (BID) is an 8-byte value unique to each switch. The BID consists of a 2-byte priority field and a 6-byte system ID, with the system ID being based on a universal (burned-in) MAC address in each switch. Using a burned-in MAC address ensures that each switch’s BID will be unique.

STP defines messages called bridge protocol data units (BPDUs), which switches use to exchange information with each other. The most common BPDU, called a hello BPDU, lists many details, including the sending switch’s BID. Switches can tell which switch sent which hello BPDU via its BID. Table 8-4 lists some of the key information in the hello BPDU.

For the time being, just keep the first three items from Table 8-4 in mind, as the following sections work through the three steps for how STP chooses the interfaces to place into a forwarding state. Next, the text examines the three main steps in the STP process.

If a tie occurs based on the priority portion of the BID, the switch with the lowest MAC address portion of the BID is the root. No other tiebreaker should be needed because switches use one of their own universal (burned-in) MAC addresses as the second part of their BIDs. So if the priorities tie, and one switch uses a MAC address of 0200.0000.0000 as part of the BID and the other uses 0911.1111.1111, the first switch (MAC 0200.0000.0000) becomes the root switch.

STP elects a root switch in a manner not unlike a political election. The process begins with all switches claiming to be the root by sending hello BPDUs listing their own BID as the root BID. If a switch hears a hello that lists a better (lower) BID, that switch stops advertising itself as root and starts forwarding the superior hello. The hello sent by the better switch lists the better switch’s BID as the root. It works like a political race in which a less-popular candidate gives up and leaves the race, throwing his support behind the more popular candidate. Eventually, everyone agrees which switch has the best (lowest) BID, and everyone supports the elected switch—which is where the political race analogy falls apart.

Figure 8-3 shows the beginning of the root election process. In this case, SW1 has advertised itself as root, as have SW2 and SW3. However, SW2 now believes that SW1 is a better root, so SW2 is now forwarding the hello originating at SW1. So, at this point, the figure shows SW1 is saying hello, claiming to be root; SW2 agrees, and is forwarding SW1’s hello that lists SW1 as root; but, SW3 is still claiming to be best, sending its own hello BPDUs, listing SW3’s BID as the root.

Two candidates still exist in Figure 8-3: SW1 and SW3. So who wins? Well, from the BID, the lower-priority switch wins; if a tie occurs, the lower MAC address wins. As shown in the figure, SW1 has a lower BID (32769:0200.0001.0001) than SW3 (32769:0200.0003.0003), so SW1 wins, and SW3 now also believes that SW1 is the better switch. Figure 8-4 shows the resulting hello messages sent by the switches.

After the election is complete, only the root switch continues to originate STP hello BPDU messages. The other switches receive the hellos, update the sender’s BID field (and root cost field), and forward the hellos out other interfaces. The figure reflects this fact, with SW1 sending hellos at Step 1, and SW2 and SW3 independently forwarding the hello out their other interfaces at Step 2.

Summarizing, the root election happens through each switch claiming to be root, with the best switch being elected based on the numerically lowest BID. Breaking down the BID into its components, the comparisons can be made as follows:

The lowest priority

If that ties, the lowest switch MAC address

The idea of a switch’s cost to reach the root switch can be easily seen for humans. Just look at a network diagram that shows the root switch, lists the STP cost associated with each switch port, and the nonroot switch in question. Switches use a different process than looking at a network diagram, of course, but using a diagram can make it easier to learn the idea.

Figure 8-5 shows just such a diagram, with the same three switches shown in the last several figures. SW1 has already won the election as root, and the figure considers the cost from SW3’s perspective.

SW3 has two possible physical paths to send frames to the root switch: the direct path to the left, and the indirect path to the right through switch SW2. The cost is the sum of the costs of all the switch ports the frame would exit if it flowed over that path. (The calculation ignores the inbound ports.) As you can see, the cost over the direct path out SW3’s G0/1 port has a total cost of 5, and the other path has a total cost of 8. SW3 picks its G0/1 port as root port because it is the port that is part of the least-cost path to send frames to the root switch.

Switches come to the same conclusion, but using a different process. Instead, they add their local interface STP cost to the root cost listed in each received hello BPDU. The STP port cost is simply an integer value assigned to each interface, per VLAN, for the purpose of providing an objective measurement that allows STP to choose which interfaces to add to the STP topology. The switches also look at their neighbor’s root cost, as announced in the hello BPDUs received from each neighbor.

Figure 8-6 shows an example of how switches calculate their best root cost and then choose their root port, using the same topology and STP costs as shown in Figure 8-5. STP on SW3 calculates its cost to reach the root over the two possible paths by adding the advertised cost (in hello messages) to the interface costs listed in the figure.

Focus on the process for a moment. The root switch sends hellos, with a listed root cost of 0. The idea is that the root’s cost to reach itself is 0.

Next, look on the left of the figure. SW3 takes the received cost (0) from the hello sent by SW1, adds the interface cost (5) of the interface on which that hello was received. SW3 calculates that the cost to reach the root switch, out that port (G0/1), is 5.

On the right side, SW2 has realized its best cost to reach the root is cost 4. So, when SW2 forwards the hello toward SW3, SW2 lists a root cost of 4. SW3’s STP port cost on port G0/2 is 4, so SW3 determines a total cost of 8 to reach the root out its G0/2 port.

As a result of the process depicted in Figure 8-6, SW3 chooses Gi0/1 as its RP, because the cost to reach the root switch through that port (5) is lower than the other alternative (Gi0/2, cost 8). Similarly, SW2 chooses Gi0/2 as its RP, with a cost of 4 (SW1’s advertised cost of 0 plus SW2’s Gi0/2 interface cost of 4). Each switch places its root port into a forwarding state.

In most cases, the first tiebreaker solves the problem—the lowest neighbor BID. For instance, if you refer to Figure 8-6 in the previous section, imagine that SW3’s root cost tied over both paths to reach the root (SW1). SW3 then looks at the BIDs of its two neighbors (SW1 and SW2) and picks the one that is lowest. In Figure 8-6, SW1’s BID is lowest, so SW3 would choose as its root port the port connected to that neighbor—namely, SW3’s G0/1 port.

In some other cases, STP needs even more tiebreakers. Specifically, when two switches connect with multiple links, as shown in Figure 8-7, the neighbor’s BID will be equal.

In this particular example, SW2 becomes the root, and SW1 needs to choose its RP. SW1’s port costs tie, at 19 each, so SW1’s root cost ties over each path at cost 19. SW2 sends hellos over each link to SW1, so SW1 cannot break the tie based on the neighbor BID, because both neighbor BIDs list SW2’s BID. So, SW1 has to consider the other two tiebreakers, in order: the neighboring switch ports’ port priority, and if that ties, the neighboring switch ports’ internal port number (with lowest being best).

In Figure 8-7, SW1 would see that the hello that entered its F0/14 port has a neighbor’s port priority of 112, better than the other port’s priority of 128, so SW1 would choose F0/14 as its root port.

The following list summarizes the criteria for choosing a root port, with all the tiebreakers listed:

1. Choose based on the least cost path to the root. If a tie occurs...

2. Choose based on the lowest BID of the neighboring bridge. If a tie occurs...

3. Choose based on the lowest port priority of the neighboring switch ports. If a tie occurs...

4. Choose based on the lowest internal port number on the neighboring switch ports.

For example, earlier Figure 8-4 showed in bold text the parts of the hello messages from both SW2 and SW3 that determine the choice of DP on that segment. Note that both SW2 and SW3 list their respective cost to reach the root switch (cost 4 on SW2 and cost 5 on SW3). SW2 lists the lower cost, so SW2’s Gi0/1 port is the designated port on that LAN segment.

All DPs are placed into a forwarding state; so in this case, SW2’s Gi0/1 interface will be in a forwarding state.

If the advertised costs tie, the switches break the tie by choosing the switch with the lower BID. In this case, SW2 would also have won, with a BID of 32769:0200.0002.0002 versus SW3’s 32769:0200.0003.0003.

The only interface that does not have a reason to be in a forwarding state on the three switches in the examples shown in Figures 8-3 through 8-6 is SW3’s Gi0/2 port. So, the STP process is now complete. Table 8-5 outlines the state of each port and shows why it is in that state.

Switches have a way to create a default BID, by taking a default priority value and adding a universal MAC address that comes with the switch hardware. However, engineers typically want to choose which switch becomes the root. Chapter 9, “Cisco Nexus Spanning Tree Protocol Implementation,” shows how to configure a Cisco switch to override its default BID setting to make a switch become root.

Port costs also have default values, per port, per VLAN. You can configure these port costs, or you can use the default values. Table 8-6 lists the default port costs defined by IEEE; Cisco uses these same defaults.

With STP enabled, all working switch interfaces will settle into an STP forwarding or blocking state, even access ports. For switch interfaces connected to hosts or routers, which do not use STP, the switch still forwards hellos on to those interfaces. By virtue of being the only device sending a hello on to that LAN segment, the switch is sending the least-cost hello on to that LAN segment, making the switch become the designated port on that LAN segment. So, STP puts working access interfaces into a forwarding state as a result of the designated port part of the STP process.

The root switch sends a new hello BPDU every 2 seconds by default. Each nonroot switch forwards the hello on all DPs, but only after changing the items listed in the hello. The switch sets the root cost to that local switch’s calculated root cost. The switch also sets the “sender’s bridge ID” field to its own BID. (The root’s BID field is not changed.)

By forwarding the received (and changed) hellos out all DPs, all switches continue to receive hellos every 2 seconds. The following steps summarize the steady-state operation when nothing is currently changing in the STP topology:

Step 1. The root creates and sends a hello BPDU, with a root cost of 0, out all its working interfaces (those in a forwarding state).

Step 2. The nonroot switches receive the hello on their root ports. After changing the hello to list their own BID as the sender’s BID, and listing that switch’s root cost, the switches forward the hello out all designated ports.

Step 3. Steps 1 and 2 repeat until something changes.

Each switch relies on these periodic received hellos from the root as a way to know that its path to the root is still working. When a switch ceases to receive the hellos, or receives a hello that lists different details, something has failed, so the switch reacts and starts the process of changing the spanning-tree topology.

If a switch does not get an expected hello BPDU within the hello time, the switch continues as normal. However, if the hellos do not show up again within the MaxAge time, the switch reacts by taking steps to change the STP topology. With default settings, MaxAge is 20 seconds (10 times the default hello timer of 2 seconds). So, a switch would go 20 seconds without hearing a hello before reacting.

After MaxAge expires, the switch essentially makes all its STP choices again, based on any hellos it receives from other switches. It reevaluates which switch should be the root switch. If the local switch is not the root, it chooses its RP. And it determines whether it is the DP on each of its other links. The best way to describe STP convergence is to show an example using the same familiar topology. Figure 8-8 shows the same familiar figure, with SW3’s Gi0/2 in a blocking state, but SW1’s Gi0/2 interface has just failed.

SW3 reacts to the change because SW3 fails to receive its expected hellos on its Gi0/1 interface. However, SW2 does not need to react because SW2 continues to receive its periodic hellos in its Gi0/2 interface. In this case, SW3 reacts either when the MaxAge time passes without hearing the hellos, or as soon as SW3 notices that interface Gi0/1 has failed. (If the interface fails, the switch can assume that the hellos will not be arriving in that interface anymore.)

Now that SW3 can act, it begins by reevaluating the choice of root switch. SW3 still receives the hellos from SW2, as forwarded from the root (SW1). SW1 still has a lower BID than SW3; otherwise, SW1 would not have already been the root. So, SW3 decides that SW1 is still the best switch and that SW3 is not the root.

Next, SW3 reevaluates its choice of RP. At this point, SW3 is receiving hellos on only one interface: Gi0/2. Whatever the calculated root cost, Gi0/2 becomes SW3’s new RP. (The cost would be 8, assuming the STP costs had no changes since Figures 8-5 and 8-6.)

SW3 then reevaluates its role as DP on any other interfaces. In this example, no real work needs to be done. SW3 was already the DP on interface Fa0/13, and it continues to be the DP because no other switches connect to that port.

Switches can simply move immediately from forwarding to blocking state, but they must take extra time to transition from blocking state to forwarding state. For instance, when a switch formerly used port G0/1 as its RP (a role), that port was in a forwarding state. After convergence, G0/1 might be neither an RP nor a DP; the switch can immediately move that port to a blocking state.

When a port that was formerly blocked needs to transition to forwarding, the switch first puts the port through two intermediate interface states. These temporary states help prevent temporary loops:

Listening: Like in the blocking state, the interface does not forward frames. The switch removes old, stale (unused) MAC table entries for which no frames are received from each MAC address during this period. These stale MAC table entries could be the cause of the temporary loops.

Learning: Interfaces in this state still do not forward frames, but the switch begins to learn the MAC addresses of frames received on the interface.

STP moves an interface from blocking to listening, then to learning, and then to forwarding state. STP leaves the interface in each interim state for a time equal to the forward delay timer, which defaults to 15 seconds. As a result, a convergence event that causes an interface to change from blocking to forwarding requires 30 seconds to transition from blocking to forwarding. In addition, a switch might have to wait MaxAge seconds before even choosing to move an interface from blocking to forwarding state.

For example, follow what happens with the initial STP topology shown in Figures 8-3 through 8-6, with the SW1-to-SW3 link failing, as shown in Figure 8-8. If SW1 simply quit sending hello messages to SW3, but the link between the two did not fail, SW3 would wait MaxAge seconds before reacting (20 seconds by default). SW3 would actually quickly choose its ports’ STP roles, but then wait 15 seconds each in the listening and learning states on interface Gi0/2, resulting in a 50-second convergence delay.

Table 8-8 summarizes spanning tree’s various interface states for easier review.

Even with such an amazingly long life, STP has gone through several changes over these decades—some small, some large. For instance, Cisco added proprietary features to make improvements to STP. In some cases, the IEEE added these same improvements, or something like them, to later IEEE standards, whether as a revision of the 802.1D standard or as an additional standard. And STP has gone through one major revision that improves convergence, called the Rapid Spanning Tree Protocol (RSTP), as originally defined in IEEE 802.1w.

This final of three major sections of this chapter briefly discusses the basics of several of these optional features that go beyond the base 802.1D STP concepts, including Port-Channel, PortFast, and BPDU Guard.

Port-Channel combines multiple parallel segments of equal speed between the same pair of switches, bundled into a Port-Channel. The switches treat the Port-Channel as a single interface with regard to STP. As a result, if one of the links fails, but at least one of the links is up, STP convergence does not have to occur. For example, Figure 8-9 shows the familiar three-switch network, but now with two Gigabit Ethernet connections between each pair of switches.

With each pair of Ethernet links configured as a Port-Channel, STP treats each Port-Channel as a single link. In other words, both links to the same switch must fail for a switch to need to cause STP convergence. Without Port-Channel, if you have multiple parallel links between two switches, STP blocks all the links except one. With Port-Channel, all the parallel links can be up and working at the same time, while reducing the number of times STP must converge, which in turn makes the network more available.

When a switch makes a forwarding decision to send a frame out a Port-Channel, the switch then has to take an extra step in logic: Out which physical interface does it send the frame? The switches have load-balancing logic that let them pick an interface for each frame, with a goal of spreading the traffic load across all active links in the channel. As a result, a LAN design that uses Port-Channel makes much better use of the available bandwidth between switches, while also reducing the number of times that STP must converge.

PortFast is most appropriate for connections to end-user devices. If you turn on PortFast on ports connected to end-user devices, when an end-user PC boots, the switch port can move to an STP forwarding state and forward traffic as soon as the PC NIC is active. Without PortFast, each port must wait while the switch confirms that the port is a DP, and then wait while the interface sits in the temporary listening and learning states before settling into the forwarding state.

An attacker could connect a switch to one of these ports, one with a low STP priority value, and become the root switch. The new STP topology could have worse performance than the desired topology.

The attacker could plug into multiple ports, into multiple switches, become root, and actually forward much of the traffic in the LAN. Without the networking staff realizing it, the attacker could use a LAN analyzer to copy large numbers of data frames sent through the LAN.

Users could innocently harm the LAN when they buy and connect an inexpensive consumer LAN switch (one that does not use STP). Such a switch, without any STP function, would not choose to block any ports and would likely cause a loop.

The Cisco BPDU Guard feature helps defeat these kinds of problems by disabling a port if any BPDUs are received on the port. So, this feature is particularly useful on ports that should be used only as an access port and never connected to another switch.

In addition, the BPDU Guard feature helps prevent problems with PortFast. PortFast should be enabled only on access ports that connect to user devices, not to other LAN switches. Using BPDU Guard on these same ports makes sense because if another switch connects to such a port, the local switch can disable the port before a loop is created.

RSTP (802.1w) works just like STP (802.1D) in several ways:

It elects the root switch using the same parameters and tiebreakers.

It elects the root port on nonroot switches with the same rules.

It elects designated ports on each LAN segment with the same rules.

It places each port in either forwarding or blocking state, although RSTP calls the blocking state the discarding state.

RSTP can be deployed alongside traditional 802.1D STP switches, with RSTP features working in switches that support it, and traditional 802.1D STP features working in the switches that support only STP.

With all these similarities, you might be wondering why the IEEE bothered to create RSTP in the first place. The overriding reason is convergence. STP takes a relatively long time to converge (50 seconds with the default settings when all the wait times must be followed). RSTP improves network convergence when topology changes occur, usually converging within a few seconds, or in poor conditions, in about 10 seconds.

IEEE 802.1w RSTP changes and adds to IEEE 802.1D STP in ways that avoid waiting on STP timers, resulting in quick transitions from forwarding to blocking state, and vice versa. Specifically, RSTP, compared to STP, defines more cases in which the switch can avoid waiting for a timer to expire. For example:

It adds a new mechanism to replace the root port without any waiting to reach a forwarding state (in some conditions).

It adds a new mechanism to replace a designated port, without any waiting to reach a forwarding state (in some conditions).

RSTP also lowers the waiting times for cases in which it must wait.

For instance, when a link remains up, but hello BPDUs simply stop arriving regularly on a port, STP requires a switch to wait for MaxAge seconds. STP defines the MaxAge timers based on 10 times the hello timer, or 20 seconds, by default. RSTP shortens this timer, defining MaxAge as three times the hello timer.

The best way to get a sense for these mechanisms is to see how the RSTP alternate port and the backup port both work. RSTP uses the term alternate port to refer to a switch’s other ports that could be used as the root port if the root port ever fails. The backup port concept provides a backup port on the local switch for a designated port, but only applies to some topologies that frankly do not happen often with a modern data center design. However, both are instructive about how RSTP works. Table 8-9 lists these RSTP port roles.

To be an alternate port, that switch port must also be hearing a hello BPDU that declares the same switch to be the root switch. For instance, in Figure 8-10, SW1 is the root. SW3 will receive hello BPDUs on two ports: G0/1 and G0/2. Both hellos list SW1’s BID as the root switch, so whichever port is not the root port meets the criteria to be an alternate port. SW3 picks G0/1 as its root port in this case, and then makes G0/2 an alternate port.

An alternate port basically works like the second-best option for the root port. The alternate port can take over for the former root port, often very rapidly, without requiring a wait in other interim RSTP states. For instance, when the root port fails, or when hellos stop arriving on the original root port, the switch moves the original root port to a disabled role, and transitions to a discarding state (the equivalent of STP’s blocking state). Without waiting on any timers, the best alternate port then becomes the new root port. That new root port also does not need to spend time in other states, such as the learning state, instead moving immediately to the forwarding state.

Figure 8-11 shows an example of RSTP convergence in which the link between SW1 and SW3 fails. The figure begins with Step 1 being the event that causes the link to fail.

The following are the steps shown in the figure:

Step 1. The link between SW1 and SW3 fails.

Step 2. SW3 and SW2 exchange RSTP messages to confirm that SW3 will now transition its former alternate port to be the root port. This action causes SW2 to flush the required MAC table entries.

Step 3. SW3 transitions G0/1 to the disabled role and G0/2 to the root port role.

Step 4. SW3 transitions G0/2 to a forwarding state immediately, without using the learning state, because this is one case in which RSTP knows the transition will not create a loop.

Once SW3 realizes its G0/1 interface has failed, the process shown in the figure takes very little time. None of the processes rely on timers, so as soon as the work can be done, the convergence completes. (This particular convergence example takes about one second in a lab.)

Both STP and RSTP use port states, but with some differences. First, RSTP keeps both the learning and forwarding states, as compared with STP, for the same purposes. However, RSTP does not even define a listening state, finding it unnecessary. Also, RSTP renames the blocking state to the discarding state and redefines its use slightly.

RSTP uses the discarding state for what 802.1D defines as two states: disabled state and blocking state. Blocking should be somewhat obvious by now: The interface can work physically, but STP/RSTP chooses to not forward traffic to avoid loops. STP’s disabled state simply means that the interface is administratively disabled. RSTP simply combines those into a single discarding state.

Table 8-10 shows the list of STP and RSTP states for comparison purposes.

RSTP also changes its algorithm processes and message content (compared to STP) to speed convergence. STP waits for a time (forward delay) in both listening and learning states. The reason for this delay in STP is that, at the same time, the switches have all been told to time out their MAC table entries. When the topology changes, the existing MAC table entries may actually cause a loop. With STP, the switches all tell each other (with BPDU messages) that the topology has changed, and to time out any MAC table entries using the forward delay timer. This removes the entries, which is good, but it causes the need to wait in both the listening and learning states for forward delay time (default 15 seconds each).

RSTP, to converge more quickly, avoids relying on timers. RSTP switches tell each other (using messages) that the topology has changed. Those messages also direct neighboring switches to flush the contents of their MAC tables in a way that removes all the potentially loop-causing entries, without a wait. As a result, RSTP creates more scenarios in which a formerly discarding port can immediately transition to a forwarding state, without waiting, and without using the learning state, as shown in the example surrounding Figure 8-11.

Figure 8-12 shows an example. SW3 and SW4 both connect to the same hub. SW4’s port E1/1 happens to win the election as the designated port (DP). The other port on SW4 that connects to the same collision domain, E1/2, acts as a backup port.

With a backup port, if the current designated port fails, SW4 can start using the backup port with rapid convergence. For instance, if SW4’s E1/1 interface fails, SW4 could transition E1/2 to the DP role, without any delay in moving from the discarding state to the forwarding state.

blocking state

BPDU Guard

bridge ID

bridge protocol data unit (BPDU)

designated port

Port-Channel

forward delay

forwarding state

hello BPDU

IEEE 802.1D

learning state

listening state

MaxAge

PortFast

root port

root switch

root cost

Spanning Tree Protocol (STP)

Rapid STP (RSTP)

IEEE 802.1w

alternate port

backup port

discarding state