Other STP Enhancement Features
| The remainder of this chapter focuses on other enhancements that Cisco has included in its IOS switches to help with STP issues. These features include BPDU skewing, Root Guard, Unidirectional Link Detection, Loop Guard, and some additional troubleshooting tips and tools to assist you in scaling STP to a large number of switches. BPDU SkewingBPDU skewing refers to the time differential between when BPDUs are expected to be received by a switch and when they are actually received. BPDU skewing can occur in any of the following situations:
When any of these three occurrences happens, switches flood the network with BPDUs to ensure that the most up-to-date information is contained in the STP topology table. When skewing occurs, a syslog message can be generated to indicate a possible problem. Of course, if it's a time of very high network activity, and if you are using PVST (BPDUs for each VLAN), this could create a lot of unnecessary syslog messages. BPDU skewing is disabled by default. When it's enabled, BPDU skewing ensures that syslog messages are generated only once every 60 seconds. To enable BPDU skewing, you cannot use the IOS you must use the CatOS's set spantree bpdu-skewing command. Root GuardRoot Guard is a Cisco feature that you can use to force a particular port to be a designated port to ensure that any switch connected to it does not become a root switch. Root Guard enables you to create an STP topology in which you explicitly control which switch becomes and stays the root switch (barring any failures). This is typically done to maintain an optimal configuration. Let's look at an example in which Root Guard can help. I'll use the network shown in the top-left portion of Figure 5.5. In this figure, there are two distribution layer switches and one access layer switch, with the left-side distribution layer switch being the root. In the bottom-right portion of the figure, a new switch is directly connected to the access layer switch. This switch has a lower switch ID than the current root, so the new switch is promoted as root and a new topology is created. In this example, if you have other switches connected to the two distribution layer switches like switch 3, and if these switches previously used switch 1 to reach the distribution layer, any resources off of switch 2 would require a switching path of switch 1, switch 3, and then switch 2. This is not an optimal configuration; especially with traffic flowing through a lower model, worse performing access layer switch. During high traffic volumes, the performance of switch 3 could be affected drastically. Figure 5.5. STP root bridge problem.
Cisco highly stresses the use of this feature in switched networks. Root Guard can be used to prevent this problem. It is configured on a per-port basis and prevents a port from becoming a root port. When configured, if a Root Guard port receives a BPDU with a better path to the root, the port is disabled and the BPDU information is ignored. Here's the message that you would see if this occurs: %SPANTREE-2-ROOTGUARDBLOCK: Port 0/5 tried to become non-designated in VLAN 3. Moved to root-inconsistent state. Given our example in Figure 5.5, when switch 4 is connected to switch 3, and if Root Guard is enabled on this port, switch 3 would disable the offending port and ignore switch 4's BPDU. By doing this, the current STP topology shown in the top-left corner of the figure would be preserved. To enable Root Guard, use the following configuration: Switch(config)# interface type slot_#/port_# Switch(config-if)# spanning-tree guard root By default, Root Guard is disabled on all interfaces. To fix the problem shown in Figure 5.5, enable Root Guard on all ports of switch 3 except the two uplink ports to switch 1 and switch 2. To examine your port's Root Guard configuration, use the show running-config interface command. To actually see the list of ports where Root Guard has detected a violation, use this command: Switch> show spanning-tree inconsistentports Name Interface Inconsistency ------- ----------------- ---------------------- VLAN001 FastEthernet 0/5 Port Type Inconsistent VLAN002 FastEthernet 0/5 Port Type Inconsistent VLAN003 FastEthernet 0/5 Port Type Inconsistent In this example, FastEthernet 0/5 has an inconsistency for VLANs 1 3. This indicates that this is a trunk connection to another switch and that the other switch is advertising a lower switch ID than the current root.
Unidirectional Link DetectionUnidirectional Link Detection (UDLD) checks to see whether unidirectional links exist between two switches and disables them. UDLD checks the physical configuration of the connection between two switches. Unidirectional connections can occur on a full-duplex connection (fiber and copper) if either the transmit wire or the receive wire is broken. By shutting down the unidirectional connection, UDLD prevents inadvertent loops and black holes (one switch is accessible, but another is not). Even though UDLD examines Layer 1 information, it operates at Layer 2 and deals with certain things that Layer 1 cannot perform or detect. For instance, one function of Layer 1 is to perform auto-negotiation to determine the duplexing and speed of an interface, as well as fault detection. UDLD performs some additional tasks, such as learning the identity of a neighboring device and disabling interfaces where only one direction of the connection is functioning. UDLD performs its detection process by periodically sending UDLD packets on enabled interfaces. If a UDLD packet is not received from a neighbor, the interface is disabled. Therefore, it's important that UDLD be enabled on both sides of the connection to prevent inadvertent interface shutdowns. By default, UDLD is enabled only for fiber-optic connections. You can enable or disable it globally, or enable or disable it on an interface-by-interface basis. To globally enable or disable UDLD, use the following configuration: Switch(config)# [no] udld enable To enable or disable UDLD on copper interfaces, use the following configuration: Switch(config)# interface type slot_#/port_# Switch(config-if)# [no] udld enable To disable UDLD on fiber-optic interfaces, use the following configuration: Switch(config)# interface type slot_#/port_# Switch(config-if)# udld disable If an interface has been disabled by UDLD and you've fixed the problem, use the udld reset command to re-enable these interfaces. They will be automatically re-enabled when the problem is fixed and the timeout period expires. To examine your UDLD configuration and operation, use this command: Switch> show udld [type slot_#/port_#] Here's an example of this command: Switch> show udld gigabitethernet0/1 Interface gi0/1 --- Port enable administrative configuration setting: Follows device default Port enable operational state: Enabled Current bidirectional state: Bidirectional Current operational state: Advertisement - Single Neighbor detected Message interval: 60 Time out interval: 5 Entry 1 Expiration time: 146 Device ID: 1 Current neighbor state: Bidirectional Device name: 0050e2827111 Port ID: Gi0/12 Neighbor echo 1 device: SAD03160123 Neighbor echo 1 port: Gi0/11 Message interval: 5 CDP Device name: 066527888 Loop GuardThe Loop Guard feature is similar to UDLD. Loop Guard is used to detect loops caused typically by unidirectional connections. Let's take a look at the example shown in Figure 5.6. In the left side of this example, there has been a connection failure between switch 1 and switch 3, causing a unidirectional connection where switch 3 can send to switch 1, but switch 1 can't send to switch 3. Given this situation, switch 3 assumes a failure on its root port and goes through the process of taking its backup port (to switch 2) and moving it through the different port states, eventually ending in the forwarding state. This would cause a one-direction loop in a clockwise direction. Figure 5.6. Unidirectional connections and Loop Guard.
Loop Guard can be used to prevent this kind of problem. Loop Guard performs an additional check: If BPDUs are no longer being received on a nondesignated port, instead of moving a port through listening, learning, and forwarding, Loop Guard instead places the port in a blocked state, marking it as inconsistent. When this occurs, you'll see the following message logged to your console: SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 0/2 in vlan 1. Moved to loop-inconsistent state. One nice feature of Loop Guard, as compared to UDLD, is that when the problem is fixed, Loop Guard has the ports transition back to the correct states, as well as generate a message on the console indicating this process: SPANTREE-2-LOOPGUARDUNBLOCK: port 0/2 restored in vlan 1. Loop Guard is disabled by default. If you want to use this feature, you should enable it on ports that are in a blocking state by default. For EtherChannels, Loop Guard ensures that the entire channel is blocked for the appropriate VLANs if a problem occurs (not just one interface in the channel). Use this command to enable Loop Guard: Switch(config)# interface type slot_#/port_# Switch(config-if)# spanning-tree guard loop Notice that this is the same command that enabled Root Guard. Loop Guard and Root Guard are mutually inclusive if you enable one, the other is automatically enabled. As you can see from this and the last section, Loop Guard and UDLD are similar in function. Table 5.7 compares these two features.
As you can see in Table 5.7, UDLD and Loop Guard have some similar functions, but differ in what they accomplish. If there is a software problem in which a switch is prevented from sending BPDUs, Loop Guard will detect it, but UDLD won't. However, if there is a shared medium connection, Loop Guard won't function, but UDLD will. Another advantage of UDLD is that if a connection failure causes a unidirectional connection on one connection in an EtherChannel, UDLD disables only the specific connection in the channel, whereas Loop Guard disables the entire channel for the specific VLAN.
Additional Troubleshooting Tips and ToolsAs you saw in the preceding chapter and this one, setting up STP is not a simple process. Many problems can occur that can complicate the operation of STP. The previous section discussed issues with unidirectional connections; however, there are many other networking problems that can create havoc with STP. When troubleshooting STP, potential problems include duplex mismatch, unidirectional link failure, frame corruption, and resource errors. ProblemsOne of the first STP enhancement features discussed in this chapter was the use of Cisco's PortFast feature to reduce the amount of times STP is run based on port state changes. With PortFast, a port is kept in a forwarding state and a change of state in PortFast doesn't cause STP to rerun. However, if you attach a switch to a PortFast port and this switch has connections to other parts of your network, you would inadvertently be creating Layer 2 loops. When using PortFast, you should complement it with the BPDU Guard or filtering features. Something as simple as mismatched duplexing can also create STP problems. If one side is set to half-duplex and the other to full duplex through an auto-negotiation problem, and both sides are sending frames simultaneously, a collision occurs. Unfortunately, the collision detection mechanism on the full-duplex side won't be able to detect this. If this causes BPDUs to be missed, the STP algorithm might rerun itself. In a worst-case situation, a loop might occur while a port in a blocking state is accidentally brought to a forwarding state. If a bad wire connection is corrupting some of your frames, it can also lead to STP issues, especially if it's the BPDUs that are being corrupted. Or, if your switch is continually performing STP functions (which are done in software), this could create an over-utilization problem on your switch, causing STP instability problems. Troubleshooting StepsWhenever you experience STP problems in your network, you should approach the problem in a methodical manner. Use the following steps to help you with your troubleshooting:
debug CommandsLike Cisco routers, Catalyst switches support the debug command. This command enables you to display detailed events that are concerned with a specific process. Care must be taken when using these commands because they're very resource-intensive. Use of these commands requires that you be in Privilege EXEC mode when you execute them. Table 5.8 displays some of the more common debug commands that you would use to troubleshoot STP problems.
To disable a debug command, preface it with the no parameter. To disable all debugging on the switch, use the no debug all command. |
EAN: 2147483647
Pages: 171