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 Skewing

BPDU 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:

  • STP topology changes occur

  • One of STP's timers expires

  • A BPDU is not received within the expected time interval

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 Guard

Root 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.

graphics/05fig05.gif

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.

graphics/alert_icon.gif

Root Guard forces a particular port to be a designated port to ensure that a switch connected to it does not become a root switch. If a Root Guard port receives a BPDU with a better path to the root, the port is disabled (marked as inconsistent) and the BPDU information is ignored. Use the spanning-tree guard root command to enable this feature.


Unidirectional Link Detection

Unidirectional 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 Guard

The 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.

graphics/05fig06.gif

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.

Table 5.7. Comparing UDLD and Loop Guard

Operation

UDLD

Loop Guard

Configuration?

Per port or global

Per port or global

Enabled on which ports? state (redundant ports)

Uplink ports

All ports in a blocked

Blocking affects?

Single port

Single port or VLAN

Re-enabling inconsistent ports?

After timeout period expires

After problem is fixed

Unidirectional link protection?

Yes

Yes

Protects against missing BPDUs from neighbor?

No

Yes

Protects from wiring configuration problems?

Yes

No

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.

Choosing a Solution: UDLD Versus Loop Guard

Given the differences between the two, Cisco recommends that you use both UDLD and Loop Guard to protect yourself completely against STP software issues as well as unidirectional connections.


graphics/alert_icon.gif

Know the similarities and differences between UDLD and Loop Guard features shown in Table 5.7.


Additional Troubleshooting Tips and Tools

As 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.

Problems

One 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 Steps

Whenever 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:

  1. Have a network diagram in front of you that describes the physical connections between the switches as well as the default STP topology: who the root switch is, what ports are root and designated ports, and what ports are redundant links and in a blocked state. You'll also want to create a diagram with the MAC addresses for the root switch and other switches in the network for handy reference.

  2. Use show commands to verify whether a Layer 2 loop exists and which switch or switches are causing the loop problem. Check the port utilization if it is running high, it might indicate a loop.

  3. Examine the status of the interfaces to see the STP state that they're in as well as whether they're operating correctly. If they aren't, pinpoint the problem and fix it. In the meantime, if a loop exists, break it by disabling a port in the loop.

  4. Make sure that the CPU utilization is not running high, which could be causing STP software problems. If this is a problem, disable all unnecessary features to reduce your CPU load.

  5. When troubleshooting certain STP problems, you might want to disable certain STP features to simplify your troubleshooting process. For instance, you might want to disable all interfaces in an EtherChannel to ensure that it isn't the problem.

graphics/alert_icon.gif

Remember the five steps of troubleshooting STP problems, especially the step of temporarily disabling ports involved in a loop.


debug Commands

Like 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.

Table 5.8. STP debug Commands

Command

Explanation

debug spanning-tree all

Displays all messages for STP

debug spanning-tree events

Displays a message only when an STP event occurs

debug spanning-tree backbonefast

Displays messages related to the operation of BackboneFast

debug spanning-tree uplinkfast

Displays messages related to the operation of UplinkFast

debug spanning-tree bpdu

Displays messages when sending or receiving BPDUs

To disable a debug command, preface it with the no parameter. To disable all debugging on the switch, use the no debug all command.



BCMSN Exam Cram 2 (Exam Cram 642-811)
CCNP BCMSN Exam Cram 2 (Exam Cram 642-811)
ISBN: 0789729911
EAN: 2147483647
Year: 2003
Pages: 171
Authors: Richard Deal

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net