Protecting the Spanning Tree Protocol Topology - Working with Redundant Links - CCNP Routing and Switching SWITCH 300-115 Official Cert Guide (2015)

CCNP Routing and Switching SWITCH 300-115 Official Cert Guide (2015)

Part III. Working with Redundant Links

Chapter 8. Protecting the Spanning Tree Protocol Topology

This chapter covers the following topics that you need to master for the CCNP SWITCH exam:

Image Protecting Against Unexpected BPDUs: This section covers the Root Guard and BPDU Guard features, which protect against unexpected root candidates and unexpected BPDUs, respectively.

Image Protecting Against Sudden Loss of BPDUs: This section discusses the Loop Guard and Unidirectional Link Detection (UDLD) features, which detect and protect against the loss of root bridge BPDUs and conditions causing unidirectional links, respectively.

Image Using BPDU Filtering to Disable STP on a Port: This section explains how to filter BPDUs on a switch port to prevent the port from participating in STP altogether. Bridging loops are neither detected nor prevented.

Image Troubleshooting STP Protection: This section summarizes the commands that diagnose or verify actions to protect the topology.

Achieving and maintaining a loop-free Spanning Tree Protocol (STP) topology revolves around the simple process of sending and receiving bridge protocol data units (BPDUs). Under normal conditions, with all switches playing fairly and according to the rules, a loop-free topology is determined dynamically.

This chapter discusses two basic conditions that can occur to disrupt the loop-free topology (even while STP is running):

Image On a port that has not been receiving BPDUs, BPDUs are not expected. When BPDUs suddenly appear for some reason, the STP topology can reconverge to give unexpected results.

Image On a port that normally receives BPDUs, BPDUs always are expected. When BPDUs suddenly disappear for some reason, a switch can make incorrect assumptions about the topology and unintentionally create loops.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt based on your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 8-1 outlines the major headings in this chapter and the “Do I Know This Already?” quiz questions that go with them. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”

Image

Table 8-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

1. Why is it important to protect the placement of the root bridge?

a. To keep two root bridges from becoming active

b. To keep the STP topology stable

c. So all hosts have the correct gateway

d. So the root bridge can have complete knowledge of the STP topology

2. Which of the following features protects a switch port from accepting superior BPDUs?

a. STP Loop Guard

b. STP BPDU Guard

c. STP Root Guard

d. UDLD

3. Which of the following commands can you use to enable STP Root Guard on a switch port?

a. spanning-tree root guard

b. spanning-tree root-guard

c. spanning-tree guard root

d. spanning-tree rootguard enable

4. Where should the STP Root Guard feature be enabled on a switch?

a. All ports

b. Only ports where the root bridge should never appear

c. Only ports where the root bridge should be located

d. Only ports with PortFast enabled

5. Which of the following features protects a switch port from accepting BPDUs when PortFast is enabled?

a. STP Loop Guard

b. STP BPDU Guard

c. STP Root Guard

d. UDLD

6. To maintain a loop-free STP topology, which one of the following should a switch uplink be protected against?

a. A sudden loss of BPDUs

b. Too many BPDUs

c. The wrong version of BPDUs

d. BPDUs relayed from the root bridge

7. Which of the following commands can enable STP Loop Guard on a switch port?

a. spanning-tree loop guard

b. spanning-tree guard loop

c. spanning-tree loop-guard

d. spanning-tree loopguard enable

8. STP Loop Guard detects which of the following conditions?

a. The sudden appearance of superior BPDUs

b. The sudden lack of BPDUs

c. The appearance of duplicate BPDUs

d. The appearance of two root bridges

9. Which of the following features can actively test for the loss of the receive side of a link between switches?

a. POST

b. BPDU

c. UDLD

d. STP

10. UDLD must detect a unidirectional link before which of the following?

a. The Max Age timer expires.

b. STP moves the link to the Blocking state.

c. STP moves the link to the Forwarding state.

d. STP moves the link to the Listening state.

11. What must a switch do when it receives a UDLD message on a link?

a. Relay the message on to other switches

b. Send a UDLD acknowledgment

c. Echo the message back across the link

d. Drop the message

12. Which of the following features effectively disables spanning-tree operation on a switch port?

a. STP PortFast

b. STP BPDU filtering

c. STP BPDU Guard

d. STP Root Guard

13. To reset switch ports that have been put into the errdisable mode by UDLD, which one of the following commands should you use?

a. clear errdisable udld

b. udld reset

c. no udld

d. show udld errdisable

Foundation Topics

Protecting Against Unexpected BPDUs

A network running STP uses BPDUs to communicate between switches (bridges). Switches become aware of each other and of the topology that interconnects them. After a root bridge is elected, BPDUs are generated by the root and are relayed down through the spanning-tree topology. Eventually, all switches in the STP domain receive the root’s BPDUs so that the network converges and a stable loop-free topology forms.

To maintain an efficient topology, the placement of the root bridge must be predictable. Hopefully, you configured one switch to become the root bridge and a second one to be the secondary root. What happens when a “foreign” or rogue switch is connected to the network, and that switch suddenly is capable of becoming the root bridge? Cisco added two STP features that help prevent the unexpected: Root Guard and BPDU Guard.

Root Guard

After an STP topology has converged and becomes loop free, switch ports are assigned the following roles:

Image Root port: The one port on a switch that is closest (with the lowest root path cost) to the root bridge.

Image Designated port: The port on a LAN segment that is closest to the root. This port relays, or transmits, BPDUs down the tree.

Image Blocking port: Ports that are neither root nor designated ports.

Image Alternate port: Ports that are candidate root ports (they are also close to the root bridge) but are in the Blocking state. These ports are identified for quick use by the STP UplinkFast feature.

Image Forwarding port: Ports where no other STP activity is detected or expected. These are ports with normal end-user connections.

The root bridge always is expected to be seen on the root port and the alternative ports because these are “closest” (have the best-cost path) to it.

Suppose that another switch is introduced into the network with a bridge priority that is more desirable (lower) than that of the current root bridge. The new switch then would become the root bridge, and the STP topology might reconverge to a new shape. This is entirely permissible by the STP because the switch with the lowest bridge ID always wins the root election.

However, this is not always desirable for you, the network administrator, because the new STP topology might be something totally unacceptable. In addition, while the topology is reconverging, your production network might become unavailable.

Image

The Root Guard feature was developed as a means to control where candidate root bridges can be connected and found on a network. Basically, a switch learns the current root bridge’s bridge ID. If another switch advertises a superior BPDU, or one with a better bridge ID, on a port where Root Guard is enabled, the local switch will not allow the new switch to become the root. As long as the superior BPDUs are being received on the port, the port will be kept in the root-inconsistent STP state. No data can be sent or received in that state, but the switch can listen to BPDUs received on the port to detect a new root advertising itself.

In essence, Root Guard designates that a port can only forward or relay BPDUs; the port cannot be used to receive BPDUs. Root Guard prevents the port from ever becoming a root port where BPDUs normally would be received from the root bridge.

You can enable Root Guard only on a per-port basis. By default, it is disabled on all switch ports. To enable it, use the following interface configuration command:

Switch(config-if)# spanning-tree guard root

When the superior BPDUs no longer are received, the port is cycled through the normal STP states to return to normal use.

Use Root Guard on switch ports where you never expect to find the root bridge for a VLAN. In fact, Root Guard affects the entire port so that a root bridge never can be allowed on any VLAN on the port. When a superior BPDU is heard on the port, the entire port, in effect, becomes blocked.


Tip

You can display switch ports that Root Guard has put into the root-inconsistent state with the following command:

Switch# show spanning-tree inconsistentports


BPDU Guard

Recall that the traditional STP offers the PortFast feature, in which switch ports are allowed to immediately enter the Forwarding state as soon as the link comes up. Normally, PortFast provides quick network access to end-user devices, where bridging loops never are expected to form. Even while PortFast is enabled on a port, STP still is running and can detect a bridging loop. However, a loop can be detected only in a finite amount of time—the length of time required to move the port through the normal STP states.


Note

Remember that enabling PortFast on a port is not the same as disabling the STP on it.


By definition, if you enable PortFast, you do not expect to find anything that can cause a bridging loop—especially another switch or device that produces BPDUs. Suppose that a switch is connected by mistake to a port where PortFast is enabled. Now there is a potential for a bridging loop to form. An even greater consequence is that the potential now exists for the newly connected device to advertise itself and become the new root bridge.

Image

The BPDU Guard feature was developed to further protect the integrity of switch ports that have PortFast enabled. If any BPDU (whether superior to the current root or not) is received on a port where BPDU Guard is enabled, that port immediately is put into the errdisable state. The port is shut down in an error condition and must be either manually reenabled or automatically recovered through the errdisable timeout function.

By default, BPDU Guard is disabled on all switch ports. You can configure BPDU Guard as a global default, affecting all switch ports with a single command. All ports that have PortFast enabled also have BPDU Guard automatically enabled. You can use the following global configuration command to enable BPDU Guard as the default:

Switch(config)# spanning-tree portfast bpduguard default

You also can enable or disable BPDU Guard on a per-port basis, using the following interface configuration command:

Switch(config-if)# [no] spanning-tree bpduguard enable

When the BPDUs no longer are received, the port still remains in the errdisable state. See Chapter 3, “Switch Port Configuration,” for more information about recovering from the errdisable state.

You should use BPDU Guard on all switch ports where STP PortFast is enabled. This prevents any possibility that a switch will be added to the port, either intentionally or by mistake. An obvious application for BPDU Guard is on access layer switch ports where users and end devices connect. BPDUs normally would not be expected there and would be detected if a switch or hub inadvertently were connected.

Naturally, BPDU Guard does not prevent a bridging loop from forming if an Ethernet hub is connected to the PortFast port. This is because a hub does not transmit BPDUs itself; it merely repeats Ethernet frames from its other ports. A loop could form if the hub became connected to two locations in the network, providing a path for frames to be looped without any STP activity.

You never should enable BPDU Guard on any switch uplink where the root bridge is located. If a switch has multiple uplinks, any of those ports could receive legitimate BPDUs from the root—even if they are in the Blocking state as a result of the UplinkFast feature. If BPDU Guard is enabled on an uplink port, BPDUs will be detected, and the uplink will be put into the errdisable state. This will preclude that uplink port from being used as an uplink into the network.

Protecting Against Sudden Loss of BPDUs

STP BPDUs are used as probes to learn about a network topology. When the switches participating in STP converge on a common and consistent loop-free topology, BPDUs still must be sent by the root bridge and must be relayed by every other switch in the STP domain. The STP topology’s integrity then depends on a continuous and regular flow of BPDUs from the root.

What happens if a switch does not receive BPDUs in a timely manner or when it does not receive any? The switch can view that condition as acceptable—perhaps an upstream switch or an upstream link is dead. In that case, the topology must have changed, so blocked ports eventually can be unblocked again.

However, if the absence of BPDUs is actually a mistake and BPDUs are not being received even though there is no topology change, bridging loops easily can form.

Cisco has added two STP features that help detect or prevent the unexpected loss of BPDUs:

Image Loop Guard

Image Unidirectional Link Detection (UDLD)

Loop Guard

Suppose that a switch port is receiving BPDUs and the switch port is in the Blocking state. The port makes up a redundant path; it is blocking because it is neither a root port nor a designated port. It will remain in the Blocking state as long as a steady flow of BPDUs is received.

If BPDUs are being sent over a link but the flow of BPDUs stops for some reason, the last-known BPDU is kept until the Max Age timer expires. Then that BPDU is flushed, and the switch thinks there is no longer a need to block the port. After all, if no BPDUs are received, there must not be another STP device connected there.

The switch then moves the port through the STP states until it begins to forward traffic—and forms a bridging loop. In its final state, the port becomes a designated port where it begins to relay or send BPDUs downstream, when it actually should be receiving BPDUs from upstream.

Image

To prevent this situation, you can use the Loop Guard STP feature. When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports. While BPDUs are received, the port is allowed to behave normally. When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state. The port is effectively blocking at this point to prevent a loop from forming and to keep it in the nondesignated role.

When BPDUs are received on the port again, Loop Guard allows the port to move through the normal STP states and become active. In this fashion, Loop Guard automatically governs ports without the need for manual intervention.

By default, Loop Guard is disabled on all switch ports. You can enable Loop Guard as a global default, affecting all switch ports, with the following global configuration command:

Switch(config)# spanning-tree loopguard default

You also can enable or disable Loop Guard on a specific switch port by using the following interface-configuration command:

Switch(config-if)# [no] spanning-tree guard loop

Although Loop Guard is configured on a switch port, its corrective blocking action is taken on a per-VLAN basis. In other words, Loop Guard does not block the entire port; only the offending VLANs are blocked.

You can enable Loop Guard on all switch ports, regardless of their functions. The switch figures out which ports are nondesignated and monitors the BPDU activity to keep them nondesignated. Nondesignated ports are generally the alternative root ports and ports that normally are blocking.

UDLD

In a campus network, switches are connected by bidirectional links, where traffic can flow in two directions. Clearly, if a link has a physical layer problem, the two switches it connects detect a problem, and the link is shown as not connected.

What would happen if just one side of the link (receive or transmit) had an odd failure, such as malfunctioning transmit circuitry in a gigabit interface converter (GBIC) or small form factor pluggable (SFP) modules? In some cases, the two switches still might see a functional bidirectional link, although traffic actually would be delivered in only one direction. This is known as a unidirectional link.

A unidirectional link poses a potential danger to STP topologies because BPDUs will not be received on one end of the link. If that end of the link normally would be in the Blocking state, it will not be that way for long. A switch interprets the absence of BPDUs to mean that the port can be moved safely through the STP states so that traffic can be forwarded. However, if that is done on a unidirectional link, a bridging loop forms and the switch never realizes the mistake.

Image

To prevent this situation, you can use the Cisco proprietary UDLD STP feature. When enabled, UDLD interactively monitors a port to see whether the link is truly bidirectional. A switch sends special Layer 2 UDLD frames identifying its switch port at regular intervals. UDLD expects the far-end switch to echo those frames back across the same link, with the far-end switch port’s identification added.

If a UDLD frame is received in return and both neighboring ports are identified in the frame, the link must be bidirectional. However, if the echoed frames are not seen, the link must be unidirectional for some reason.

Naturally, an echo process such as this requires both ends of the link to be configured for UDLD. Otherwise, one end of the link will not echo the frames back to the originator. In addition, each switch at the end of a link sends its own UDLD messages independently, expecting echoes from the far end. This means that two echo processes are occurring on any given link.

UDLD messages are sent at regular intervals, as long as the link is active. You can configure the message interval UDLD uses. (The default is 15 seconds.) The objective behind UDLD is to detect a unidirectional link condition before STP has time to move a blocked port into the Forwarding state. To do this, the target time must be less than the Max Age timer plus two intervals of the Forward Delay timer, or 50 seconds. UDLD can detect a unidirectional link after about three times the UDLD message interval (45 seconds total, using the default).

UDLD has two modes of operation:

Image Normal mode: When a unidirectional link condition is detected, the port is allowed to continue its operation. UDLD merely marks the port as having an undetermined state and generates a syslog message.

Image Aggressive mode: When a unidirectional link condition is detected, the switch takes action to reestablish the link. UDLD messages are sent out once a second for 8 seconds. If none of those messages is echoed back, the port is placed in the errdisable state so that it cannot be used.

You configure UDLD on a per-port basis, although you can enable it globally for all fiber-optic switch ports (either native fiber or fiber-based GBIC or SFP modules). By default, UDLD is disabled on all switch ports. To enable it globally, use the following global configuration command:

Switch(config)# udld {enable | aggressive | message time seconds}

For normal mode, use the enable keyword; for aggressive mode, use the aggressive keyword. You can use the message time keywords to set the message interval to seconds, ranging from 1 to 90 seconds. The default interval is 7 seconds.

You also can enable or disable UDLD on individual switch ports, if needed, using the following interface configuration command:

Switch(config-if)# udld {enable | aggressive | disable}

Here, you can use the disable keyword to completely disable UDLD on a fiber-optic interface.


Note

The default UDLD message interval times differ among Catalyst switch platforms. Although two neighbors might have mismatched message time values, UDLD still works correctly. This is because each of the two neighbors simply echoes UDLD messages back as they are received, without knowledge of their neighbor’s own time interval. The time interval is used only to decide when to send UDLD messages and as a basis for detecting a unidirectional link from the absence of echoed messages. If you decide to change the default message time, make sure that UDLD still can detect a fault before STP decides to move a link to the Forwarding state.


You safely can enable UDLD on all switch ports. The switch globally enables UDLD only on ports that use fiber-optic media. Twisted-pair or copper media does not suffer from the physical layer conditions that allow a unidirectional link to form. However, you can enable UDLD on nonfiber links individually, if you want.

At this point, you might be wondering how UDLD can be enabled gracefully on the two end switches. Recall that in aggressive mode, UDLD disables the link if the neighbor does not reflect the messages back within a certain time period. If you are enabling UDLD on a production network, is there a chance that UDLD will disable working links before you can get the far end configured?

The answer is no. UDLD makes some intelligent assumptions when it is enabled on a link for the first time. First, UDLD has no record of any neighbor on the link. It starts sending out messages, hoping that a neighboring switch will hear them and echo them back. Obviously, the device at the far end also must support UDLD so that the messages will be echoed back.

If the neighboring switch does not yet have UDLD enabled, no messages will be echoed. UDLD will keep trying (indefinitely) to detect a neighbor and will not disable the link. After the neighbor has UDLD configured also, both switches become aware of each other and the bidirectional state of the link through their UDLD message exchanges. From then on, if messages are not echoed, the link can accurately be labeled as unidirectional.

Finally, be aware that if UDLD detects a unidirectional condition on a link, it takes action on only that link. This becomes important in an EtherChannel: If one link within the channel becomes unidirectional, UDLD flags or disables only the offending link in the bundle, not the entire EtherChannel. UDLD sends and echoes its messages on each link within an EtherChannel channel independently.

Once UDLD aggressive mode has put a switch port into the errdisable state, you must use the following command to reenable it:

Switch# udld reset

Actually, all ports errdisabled because of UDLD will be reset and reenabled simultaneously, allowing traffic to begin passing through them again. This behavior differs somewhat from other errdisable conditions, where you would use the shutdown and no shutdown commands to reenable a port.

Using BPDU Filtering to Disable STP on a Port

Ordinarily, STP operates on all switch ports in an effort to eliminate bridging loops before they can form. BPDUs are sent on all switch ports—even ports where PortFast has been enabled. BPDUs also can be received and processed if any are sent by neighboring switches.

Image

You always should allow STP to run on a switch to prevent loops. However, in special cases when you need to prevent BPDUs from being sent or processed on one or more switch ports, you can use BPDU filtering to effectively disable STP on those ports.

By default, BPDU filtering is disabled on all switch ports. You can configure BPDU filtering as a global default, affecting all switch ports with the following global configuration command:

Switch(config)# spanning-tree portfast bpdufilter default

The default keyword indicates that BPDU filtering will be enabled automatically on all ports that have PortFast enabled. If PortFast is disabled on a port, then BPDU filtering will not be enabled there.

You also can enable or disable BPDU filtering on specific switch ports by using the following interface configuration command:

Switch(config-if)# spanning-tree bpdufilter {enable | disable}

Be very careful to enable BPDU filtering only under controlled circumstances in which you are absolutely sure that a switch port will have a single host connected and that a loop will be impossible. Enable BPDU filtering only if the connected device cannot allow BPDUs to be accepted or sent. Otherwise, you should permit STP to operate on the switch ports as a precaution.


Tip

Do not confuse BPDU filtering with the BPDU Guard feature. BPDU Guard is used to detect inbound BPDUs on ports where BPDUs are not expected to be seen, then protect the STP stability by preventing those BPDUs from being processed. In contrast, BPDU filtering stops all BPDUs from being received or sent on a switch port, effectively disabling STP.


Troubleshooting STP Protection

With several different types of STP protection features available, you might need to know which (if any) has been configured on a switch port. Table 8-2 lists and describes the EXEC commands useful for verifying the features presented in this chapter.

Image

Table 8-2 Commands for Verifying and Troubleshooting STP Protection Features

Exam Preparation Tasks

Review All Key Topics

Review the most important topics in the chapter, noted with the Key Topic icon in the outer margin of the page. Table 8-3 lists a reference of these key topics and the page numbers on which each is found.

Image

Image

Table 8-3 Key Topics for Chapter 8

Complete Tables and Lists from Memory

There are no memory tables in this chapter.

Define Key Terms

Define the following key terms from this chapter, and check your answers in the glossary:

Root Guard

superior BPDU

BPDU Guard

Loop Guard

UDLD

BPDU filtering

Use Command Reference to Check Your Memory

This section includes the most important configuration and EXEC commands covered in this chapter. It might not be necessary to memorize the complete syntax of every command, but you should remember the basic keywords that are needed.

With so many similar and mutually exclusive STP protection features available, you might have a hard time remembering which ones to use where. Use Figure 8-1 as a quick reference.

Image

Figure 8-1 Guidelines for Applying STP Protection Features in a Network

Figure 8-1 shows two backbone switches (Switch A and B), along with an access layer switch (Switch C), with redundant uplinks. Users are connected to the access switch, where PortFast is in use. An additional access switch (Switch D) has an uplink to access layer switch C. All switch-to-switch links are fiber-based Gigabit Ethernet. Obviously, a root bridge never should appear out of Switch D.

To test your memory of the STP protection feature commands, cover the rightmost columns of Tables 8-4 and 8-5 with a piece of paper, read the description on the left side, then see how much of the command you can remember.

Image

Table 8-4 STP Protection Configuration Commands

Image

Table 8-5 STP Protection Activity Commands

Remember that the CCNP exam focuses on practical or hands-on skills that are used by a networking professional.