Spanning Tree PortFast causes an interface configured as a Layer 2 access port to enter the forwarding state immediately, bypassing the listening and learning states. Enable PortFast on Layer 2 access ports connected to a single workstation or server to allow those devices to connect to the network immediately, rather than waiting for spanning tree to converge. In Figure 6-1, a server and workstation are attached to an access switch through ports that have the PortFast feature enabled.

Figure 6-1. Sample PortFast Scenario

Figure 6-2 illustrates the modification in the STP state machine for interfaces configured for the PortFast feature. As illustrated in the figure, the STP state jumps directly from blocking to forwarding without going through the listening and learning state. In addition, PortFast suppresses topology change notifications.

Figure 6-2. STP State Machine with PortFast

[no] spanning-tree portfast

Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#interface FastEthernet 3/27
Switch(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
 host. Connecting hubs, concentrators, switches, bridges, etc... to this
 interface  when portfast is enabled, can cause temporary bridging loops.
 Use with CAUTION

%Portfast has been configured on FastEthernet3/27 but will only
 have effect when the interface is in a non-trunking mode.
Switch(config-if)#end
Switch#
Switch#show spanning-tree interface FastEthernet 3/27 portfast
VLAN0001         enabled

spanning-tree portfast default

switchport mode host

SwitchB#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
SwitchB(config)#interface fastEthernet 3/9
SwitchB(config-if)#switchport host
switchport mode will be set to access
spanning-tree portfast will be enabled
channel group will be disabled
SwitchB(config-if)#end
SwitchB#

UplinkFast provides fast convergence after a direct link failure if one or more redundant Layer 2 links exist. UplinkFast defines interfaces in an uplink group on a per-VLAN basis; only one interface is forwarding at any given time. Specifically, an uplink group consists of the root port (which is forwarding) and a set of blocked ports. Typically, only a single blocking interface exists, but there is no limit to the number of blocking or alternate links. The uplink group provides an alternate path in case the currently forwarding link fails.

Figure 6-3 shows an example of a topology with switch A deployed in the Building Access submodule with uplink connections to the root switch over link 2 and the backup root switch over link 3 (both of these switches are in the Building Distribution submodule.) Initially, the port on switch A connected to link 2 is in the forwarding state, and the port connected to link 3 is in the blocking state.

Figure 6-3. Network Scenario with UplinkFast Enabled

As shown in Figure 6-3, when switch A detects a link failure on the currently active link 2 on the root port (a direct link failure), UplinkFast unblocks the blocked port on switch A and transitions it to the forwarding state without going through the listening and learning states. This switchover occurs within 5 seconds.

spanning-tree uplinkfast [max-update-rate max-update-rate]

Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#spanning-tree uplinkfast
Switch(config)#spanning-tree uplinkfast max-update-rate 400
Switch(config)#end
Switch#

Switch#show spanning-tree uplinkfast
UplinkFast is enabled
Station update rate set to 400 packets/sec.
UplinkFast statistics
-----------------------
Number of transitions via uplinkFast (all VLANs)            :14
Number of proxy multicast addresses transmitted (all VLANs) :5308
Name                 Interface List
-------------------- ------------------------------------
VLAN1                Fa6/9(fwd), Gi5/7
VLAN2                Gi5/7(fwd)
VLAN3                Gi5/7(fwd)

BackboneFast is a complementary feature to UplinkFast. Whereas UplinkFast quickly responds to failures on links directly connected to distribution switches, it does not help with indirect failures in the backbone core. BackboneFast reduces the default convergence time in situations where the root port is lost and the backup link leads through a different switch. The convergence is reduced to 30 seconds from the default 50 seconds in such scenarios. However, BackboneFast does not eliminate the forward delay time and does not support direct link failures.

When a switch receives a BPDU from a designated switch that identifies the root bridge and the designated bridge as the same switch, the switch considers the BPDU an inferior BPDU. When a switch receives an inferior BPDU, it indicates that a link to which the switch is not directly connected (an indirect link) has failed; that is, the designated switch has lost its connection to the root switch.

The designated switch transmits the BPDUs with the information that it is now the root switch and the designated switch. The receiving switch ignores the inferior BPDU for the time defined by the max age setting.

After receiving inferior BPDUs, the receiving switch tries to determine whether there is an alternate path to the root switch:

If the switch that receives the inferior BPDU has alternate paths to the root switch, it uses those alternate paths to send a root link query (RLQ) BPDU. The objective of the RLQ BPDU is to determine whether the current root switch is still alive. The RLQ BPDU propagates toward the root switch through the intermediate switches, and eventually the root switch responds. If the responding root switch is the same as the original root switch, the switch detecting the indirect link failure assumes that the root switch is still alive. The switch immediately skips to the listening state for the port receiving the inferior BPDU. This process enables faster convergence in the event of a backbone link failure.

Figure 6-4 shows an example of a topology with no link failures. Switch A, the root switch, connects directly to switch B over link L1 and to switch C over link L2. In this example, because switch B has a lower priority than switch A but a higher priority than switch C, switch B becomes the designated bridge for link 3. Consequently, the Layer 2 interface on switch C that connects directly to switch B is in the blocking state.

Figure 6-4. Network Topology with BackboneFast Enabled Before Link Failure

Next, assume that link L1 fails as shown in Figure 6-5. Switch A and switch B, the switches directly connected to this segment, instantly detect that the link is down. The blocking interface on switch C enters the forwarding state for the network to recover by itself. However, because link L1 does not directly connect to switch C, switch C does not start sending BPDUs on link L3 under the normal rules of STP until the time defined by the max age setting has expired.

Figure 6-5. Link Failure with BackboneFast Enabled

In an STP environment without BackboneFast, when link L1 fails, switch C cannot detect the failure because it does not directly connect to link L1. Because switch B directly connects to the root switch over link L1, switch B detects the failure and elects itself the root. Then, switch B begins sending configuration BPDUs to switch C, listing itself as the root.

The following steps detail actions taken by Catalyst switches with BackboneFast enabled, as shown in Figure 6-6:

Figure 6-6. Catalyst Switch with BackboneFast Enabled

In this example, switch B can recover 20 seconds faster with BackboneFast enabled on the switches than without BackboneFast enabled. The total time for the switchover is approximately 30 seconds, twice the forward delay time (using the default forward delay time of 15 seconds).

Figure 6-7 shows a new switch introduced into a shared-medium topology. BackboneFast does not affect this situation because the inferior BPDUs did not come from the recognized designated bridge (switch B). The new switch begins sending inferior BPDUs that indicate the new bridge is the root switch. However, the other switches ignore these inferior BPDUs, and the new switch learns that switch B is the designated bridge to switch A (root switch). The new switch learns the path to the root bridge by using the normal STP processes.

Figure 6-7. Adding New Switch with BackboneFast Enabled

[no] spanning-tree backbonefast

Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#spanning-tree backbonefast
Switch(config)#end
Switch#show spanning-tree backbonefast
BackboneFast is enabled

BackboneFast statistics
-----------------------
Number of transition via backboneFast (all VLANs) : 0
Number of inferior BPDUs received (all VLANs)     : 0
Number of RLQ request PDUs received (all VLANs)   : 0
Number of RLQ response PDUs received (all VLANs)  : 0
Number of RLQ request PDUs sent (all VLANs)       : 0
Number of RLQ response PDUs sent (all VLANs)      : 0

BPDU Guard puts an interface configured for STP PortFast in the err-disable state upon receipt of a BPDU. The BPDU Guard disables interfaces as a preventive step to avoid a potential bridging loop.

The STP BPDU Guard shuts down PortFast-configured interfaces that receive BPDUs, rather than putting them into the STP blocking state (the default behavior). In a valid configuration, PortFast-configured interfaces should not receive BPDUs. Reception of a BPDU by a PortFast-configured interface signals an invalid configuration, such as connection of an unauthorized device. BPDU Guard provides a secure response to invalid configurations, because the administrator must manually re-enable the err-disabled interface after fixing the invalid configuration. It is also possible to set up a time-out interval after which the switch automatically tries to re-enable the interface. However, if the invalid configuration still exists, the switch err-disables the interface again.

To enable BPDU Guard or to disable BPDU Guard on a Cisco IOS–based Catalyst switch, use the following global configuration command:

[no] spanning-tree portfast bpduguard

Example 6-6 illustrates a user configuring and verifying the spanning-tree PortFast BPDU Guard feature.

Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)# spanning-tree portfast bpduguard
Switch(config)# end
Switch#show spanning-tree summary totals

Root bridge for: none.
PortFast BPDU Guard is enabled
Etherchannel misconfiguration guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short

Name                 Blocking Listening Learning Forwarding STP Active
-------------------- -------- --------- -------- ---------- ---------
            34 VLANs 0        0         0        36         36

BPDU filtering supports the ability to prevent Catalyst switches from sending BPDUs on PortFast-enabled interfaces. Ports configured for the PortFast feature typically connect to host devices. Hosts do not participate in STP and hence drop the received BPDUs. As a result, BPDU filtering prevents unnecessary BPDUs from being transmitted to host devices.

Catalyst switches support configuring BPDU filtering on a per-port or global basis. If explicitly configured on an interface, the switch does not send BPDUs and drops all BPDUs it receives.

If globally enabled, the switch changes the interface back to normal STP operation if the port receives BPDUs on the respective interface. For example, if a PortFast-enabled interface receives a BPDU, it immediately loses its PortFast status with BPDU filtering enabled. In this case, the switch disables PortFast BPDU filtering on the respective interface, and STP resumes sending BPDUs from the port toward the connected device.

Table 6-1 lists all the possible PortFast BPDU filtering combinations.

If you enable BPDU Guard on the same interface as BPDU filtering, BPDU Guard has no effect, because BPDU filtering takes precedence over BPDU Guard.

To enable PortFast BPDU filtering globally on the switch, use the following command on Cisco IOS–based Catalyst switches:

spanning-tree portfast bpdufilter default

To verify the configuration, use the following command on Cisco IOS–based Catalyst switches:

show spanning-tree summary totals

Root Guard is useful in avoiding Layer 2 loops during network anomalies. The Root Guard feature forces an interface to become a designated port, to prevent surrounding switches from becoming a root switch. In other words, Root Guard provides a way to enforce the root bridge placement in the network. Catalyst switches force Root Guard–enabled ports to be designated ports. If the bridge receives superior STP BPDUs on a Root Guard–enabled port, the port moves to a root-inconsistent STP state (effectively equal to a listening state), and the switch does not forward traffic out of that port. As a result, this feature effectively enforces the position of the root bridge.

Figure 6-8 shows a sample topology to illustrate the Root Guard feature. Switches A and B comprise the core of the network, and switch A is the root bridge for a VLAN. Switch C is an access layer switch. The link between switch B and switch C is blocking on the switch C side. Figure 6-8 shows the flow of STP BPDUs with arrows.

Figure 6-8. Network Topology with Root Guard Disabled

In Figure 6-9, when switch D is connected to switch C, it begins to participate in STP. If the priority of switch D is 0 or any value lower than that of the current root bridge, switch D becomes the root bridge for that VLAN based on normal STP guidelines. In this specific scenario, however, having switch D as the root causes the Gigabit Ethernet link that is connecting the two core switches to block, thus causing all the data in that particular VLAN to flow via a 100-Mbps link across the access layer. If there is more data flowing between the core switches in that VLAN than this link may accommodate, packet loss can occur, causing performance issues or network connectivity problems. An even worse scenario may occur if switch D is unstable and causes frequent reconvergence of the root bridge.

Figure 6-9. New Switch Introduced with Root Guard Disabled

The Root Guard feature can protect against such issues. After the Root Guard feature is enabled on a port, the switch does not allow that port to become an STP root port. The port remains as an STP-designated port. In addition, if a better BPDU is received on the port, Root Guard disables (err-disables) the port rather than processing the BPDU. If an unauthorized device starts sending BPDUs with a better bridge ID, the normal STP process would elect the new switch as the root switch. By disabling the port, the network topology is protected.

The current design recommendation is to enable Root Guard on all access ports so that a root bridge is not established through these ports. In Figure 6-9, enable Root Guard on switches A, B, and C on the following ports:

In this configuration, switch C blocks the port connecting to switch D when it receives a better (superior) BPDU. The port transitions to a special STP state (root-inconsistent), which is effectively the same as the listening state. No traffic passes through the port in root-inconsistent state.

When switch D stops sending superior BPDUs, the port unblocks again and goes through regular STP transition of listening, learning, and eventually to the forwarding state. Recovery is automatic; no intervention is required.

In addition, Catalyst switches log the following message when a Root Guard–enabled port receives a superior BPDU:

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
    Moved to root-inconsistent state

To enable Root Guard on a Layer 2 access port to force it to become a designated port, or to disable Root Guard, use the following interface-level command on Cisco IOS–based Catalyst switches:

[no] spanning-tree guard root

Example 6-7 illustrates a user enabling the Root Guard feature on FastEthernet interface 5/8 and verifying the configuration.

Switch#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#interface FastEthernet 5/8
Switch(config-if)#spanning-tree guard root
Switch(config-if)#end
Switch#show running-config interface FastEthernet 5/8
Building configuration...
Current configuration: 67 bytes
!
interface FastEthernet5/8
switchport mode access
spanning-tree guard root
end
!

Example 6-8 shows how to determine whether any interfaces are in root-inconsistent state.

Switch#show spanning-tree inconsistentports
Name                 Interface              Inconsistency
-------------------- ---------------------- ------------------
VLAN0001             FastEthernet3/1        Port Type Inconsistent
VLAN0001             FastEthernet3/2        Port Type Inconsistent
VLAN1002             FastEthernet3/1        Port Type Inconsistent
VLAN1002             FastEthernet3/2        Port Type Inconsistent
Number of inconsistent ports (segments) in the system :4

Loop Guard provides additional protection against Layer 2 forwarding loops (STP loops). A bridging loop happens when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually occurs because one of the ports of a physically redundant topology (not necessarily the STP blocking port) has stopped receiving STP BPDUs. In STP, switches rely on continuous reception or transmission of BPDUs, depending on the port role. (A designated port transmits BPDUs, whereas a nondesignated port receives BPDUs.)

When one of the ports in a physically redundant topology stops receiving BPDUs, STP conceives the topology as loop-free. Eventually, the blocking port from the alternate or backup port transitions to a designated port and then moves to the STP forwarding state, creating a bridging loop.

With the Loop Guard feature, switches do an additional check before transitioning to the STP forwarding state. If switches stop receiving BPDUs on a nondesignated port with the Loop Guard feature enabled, the switch places the port into the STP loop-inconsistent blocking state instead of moving through the listening, learning, and forwarding states.

When the Loop Guard feature places a port into the loop-inconsistent blocking state, the switch logs the following message:

SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 3/2 in vlan 3.
    Moved to loop-inconsistent state.

If a switch receives a BPDU on a port in the loop-inconsistent STP state, the port transitions through STP states according to the received BPDU. As a result, recovery is automatic, and no manual intervention is necessary. After the recovery, the switch logs the following message:

SPANTREE-2-LOOPGUARDUNBLOCK: port 3/2 restored in vlan 3.

To illustrate Loop Guard behavior, consider the example in Figure 6-10. Switch A is the root switch. Due to unidirectional link failure on the link between switch B and switch C, switch C is not receiving BPDUs from B.

Figure 6-10. Unidirectional Link Without Loop Guard

Without Loop Guard, the STP blocking port on switch C transitions to the STP listening state after the max age timer expires, and ultimately to the forwarding state after two times the forward delay time. When the port moves into the forwarding state, a bridging loop occurs, as shown in Figure 6-11.

Figure 6-11. Bridging Loop Without Loop Guard

With the Loop Guard feature enabled, the blocking port on switch C transitions into the STP loop-inconsistent state when the max age timer expires, as shown in Figure 6-12. A port in the STP loop-inconsistent state does not pass data traffic; hence, a bridging loop does not occur. The loop-inconsistent state is effectively equal to the blocking state.

Figure 6-12. Unidirectional Link with Loop Guard

You configure the Loop Guard feature on a per-port basis, although the feature blocks inconsistent ports on a per-VLAN basis. For example, on a trunk port, if BPDUs are not received for only one particular VLAN, the switch blocks only that VLAN (that is, moves the port for that VLAN to the loop-inconsistent STP state). In the case of an EtherChannel interface, the channel status goes into the inconsistent state for all the ports belonging to the channel group for the particular VLAN not receiving BPDUs. (Recall that Catalyst switches consider EtherChannel as one logical port from the STP point of view.)

Enable the Loop Guard feature on all nondesignated ports, and not just for blocking ports. More precisely, Loop Guard should be enabled on root and alternate ports for all possible combinations of active topologies. Before enabling Loop Guard, however, consider all possible failover scenarios. Figure 6-13 shows a sample scenario and indicates the ports configured for Loop Guard.

Figure 6-13. Loop Guard–Enabled Ports

Loop Guard is disabled by default on Catalyst switches. Use the following interface-level configuration command to enable Loop Guard on Cisco IOS–based Catalyst switches:

spanning-tree guard loop

When you enable Loop Guard globally for application to all ports, the switch enables Loop Guard only on ports considered to be point-to-point links. Catalyst switches consider full-duplex ports as point-to-point links. It is still possible to configure, or override, the global configuration of Loop Guard on a per-port basis.

To enable Loop Guard globally on Cisco IOS–based Catalyst switches, use the following global configuration command:

spanning-tree loopguard default

To disable Loop Guard on any specific interface on Cisco IOS–based Catalyst switches, issue the following interface configuration command:

no spanning-tree guard

To verify the Loop Guard status on an interface, issue the following EXEC command on Cisco IOS–based Catalyst switches:

show spanning-tree interface interface-id detail

Example 6-9 illustrates a user verifying the status of Loop Guard on interface FastEthernet 3/42.

Switch#show spanning-tree interface FastEthernet 3/42 detail
 Port 170 (FastEthernet3/42) of VLAN0001 is blocking
   Port path cost 19, Port priority 128, Port Identifier 128.170.
   Designated root has priority 8193, address 0009.e845.6480
   Designated bridge has priority 8193, address 0009.e845.6480
   Designated port id is 128.160, designated path cost 0
   Timers: message age 1, forward delay 0, hold 0
   Number of transitions to forwarding state: 0
   Link type is point-to-point by default
   Loop guard is enabled on the port
   BPDU: sent 1, received 4501

Loop Guard and aggressive mode UDLD functionality overlap insofar as both protect against STP failures caused by unidirectional links. These two features are different, however, in their approach to the problem and in functionality. Table 6-2 compares and contrasts the Loop Guard and aggressive mode UDLD features.

The most noticeable difference between aggressive mode UDLD and Loop Guard is in regard to STP. Aggressive mode UDLD cannot detect failures caused by problems in software in the designated switch not sending the BPDU. Problems resulting from software failures are less common than failures caused by unidirectional links that result from hardware failures. Nevertheless, aggressive mode UDLD is more robust in its ability to detect unidirectional links on EtherChannel. Loop Guard blocks all interfaces of the EtherChannel in such a failure by putting the EtherChannel into the loop-inconsistent state for a VLAN or for all VLANs, while aggressive mode UDLD disables the single port that is exhibiting problems. In addition, aggressive mode UDLD is not dependent on STP, so it supports Layer 3 links as well.

In addition, Loop Guard does not support shared links or interfaces that are unidirectional on switch Bootup. If a port is unidirectional on switch Bootup, the port never receives BPDUs and becomes a designated port. Loop Guard does not support this scenario, because the behavior is not distinguishable from normal STP operation. Aggressive mode UDLD does provide protection against such a failure scenario.

Enabling both aggressive mode UDLD and Loop Guard provides the highest level of protection against bridging loops and black holes in multilayer switched networks.

The following subsections highlight common network conditions that lead to STP problems, listed as follows:

Duplex Mismatch

Duplex mismatch on point-to-point links is a common configuration error. Duplex mismatch occurs specifically when one side of the link is manually configured as full duplex and the other side is using the default configuration for auto-negotiation. Such a configuration leads to duplex mismatch.

The worst-case scenario for a duplex mismatch is when a bridge that is sending BPDUs is configured for half duplex on a link while its peer is configured for full duplex. In Figure 6-14, the duplex mismatch on the link between switch A and switch B could potentially lead to a bridging loop. Because switch B is configured for full duplex, it starts forwarding frames even if switch A is already using the link. This is a problem for switch A, which detects a collision and runs the back-off algorithm before attempting another transmission of its frame. If there is enough traffic from switch B to switch A, every packet (including the BPDUs) sent by switch A is deferred or has a collision and is subsequently dropped. From an STP point of view, because switch B no longer receives BPDUs from switch A, it assumes the root bridge is no longer present. Consequently, switch B moves its port to switch C into the forwarding state, creating a Layer 2 loop.

Figure 6-14. Duplex Mismatch

Unidirectional Link Failure

A unidirectional link is a frequent cause for a bridging loop. An undetected failure on a fiber link or a problem with a transceiver usually causes unidirectional links. With STP enabled to provide redundancy, any condition that results in a link maintaining a physical link connected status on both link partners but operating in a one-way communication state is detrimental to network stability because it could lead to bridging loops and routing black holes. Figure 6-15 shows such an example of a unidirectional link failure affecting STP.

Figure 6-15. Unidirectional Link Failure

The link between switch A and switch B is unidirectional and drops traffic from switch A to switch B while transmitting traffic from switch B to switch A. Suppose, however, that the interface on switch B should be blocking. An interface blocks only if it receives BPDUs from a bridge that has a better priority. In this case, all the BPDUs coming from switch A are lost, and switch B eventually moves to the forwarding state, creating a loop. Note that in this case, if the failure exists at startup, STP does not converge correctly. In addition, rebooting of the bridges has absolutely no effect on this scenario.

To resolve this problem, Cisco introduced the UDLD and A-UDLD features on current-generation switches. These features can detect incorrect cabling or unidirectional links and automatically put the affected port in err-disable state. The recommended practice is to use A-UDLD on all point-to-point interfaces in any multilayer switched network. See Chapter 7 for more details about UDLD and A-UDLD.

PortFast Configuration Error

As discussed in the section titled “PortFast” earlier in this chapter, the PortFast feature, when enabled on a port, bypasses the listening and learning states of STP, and the port transitions to the forwarding mode on linkup. The fast transition may lead to bridging loops if configured on incorrect ports.

In Figure 6-16, switch A has port p1 in the forwarding state and port p2 configured for PortFast. Device B is a hub. Port p2 goes to forwarding and creates a loop between p1 and p2 as soon as the second cable plugs into switch A. The loop ceases as soon as p1 or p2 receives a BPDU that transitions one of these two ports into blocking mode. The problem with this type of transient loop condition is that if the looping traffic is intensive, the bridge may have trouble successfully sending the BPDU that stops the loop. The BPDU Guard prevents this type of event from occurring.

Figure 6-16. PortFast Configuration Error

Troubleshooting STP problems can be difficult if logical troubleshooting procedures are not deployed in advance. Occasionally, rebooting of the switches may resolve the problem temporarily, but without determining the underlying cause of the problem, the problem is likely to return.

The following steps provide a general overview of a methodology for troubleshooting STP:

The following subsections explain troubleshooting Layer 2 bridging loops in more detail.

Before you troubleshoot a bridging loop, you must understand the following basic characteristics of your network:

Knowing the basic characteristics is essential in troubleshooting any Layer 2 issue. In addition, knowledge of the network helps to focus attention on the critical ports on key devices, because most of the STP troubleshooting steps simply involve using show commands to identify error conditions.

The best way to identify a bridging loop is to capture the traffic on a saturated link and to determine whether duplicate packets are propagating. If all users in a specific bridging domain have connectivity issues at the same time, a bridging loop is a possible cause. Check the port utilization on devices and look for abnormal values. In addition, you may see other protocols break down due to the bridging loops. For example, HSRP may complain of duplicate IP addresses if a loop causes it to see its own packets. Another common message during a loop is constant flapping of MAC addresses between interfaces. In a stable network, MAC addresses do not flap. In addition, be careful not to associate a bridging loop with a packet storm caused by another anomalous event such as an Internet worm or virus.

Bridging loops have severe consequences on a bridged network. Administrators generally do not have time to look for the cause of a loop, however, preferring to restore connectivity as soon as possible and identify potential issues later. Restoring connectivity consists of the following two actions:

To log detailed events or to identify STP problems, use debug commands on Cisco IOS–based Catalyst switches. Debugging commands, if used with care, may help to identify the source of the problem.

Use the following command to enable STP debugging:

debug spanning-tree events

Example 6-10 shows sample debug output for spanning-tree events.

Switch#debug spanning-tree events
Spanning Tree event debugging is on
Switch#
*Mar  5 21:23:14.994: STP: VLAN0013 sent Topology Change Notice on Gi0/3
*Mar  5 21:23:14.994: STP: VLAN0014 sent Topology Change Notice on Gi0/4
*Mar  5 21:23:14.994: STP: VLAN0051 sent Topology Change Notice on Po3
*Mar  5 21:23:14.994: STP: VLAN0052 sent Topology Change Notice on Po4
*Mar  5 21:23:15.982: %LINEPROTO-5-UPDOWN: Line protocol on Interface
GigabitEthernet0/1, changed state to down
*Mar  5 21:23:16.958: STP: VLAN0001 Topology Change rcvd on Po1

Use the following command from global configuration mode to capture debug information into the logging buffer of a Catalyst switch (see Chapter 3, “Initial Configuration and Troubleshooting of Cisco Multilayer Switches,” for more details on system logging):

logging buffered

Investigate the blocking ports first and then the other ports. The following are several guidelines for troubleshooting port status:

High CPU utilization may lead to network instability for switches running STP. Use the show processes cpu command to check whether the CPU utilization is approaching 100 percent. Cisco Catalyst switches prioritize control packets such as BPDU over any lower-priority traffic; hence, the switch would be stable with higher CPU if it were just processing low-priority traffic.

Disabling as many features as possible reduces troubleshooting complexity. EtherChannel, for example, is a feature that bundles several different links into a single logical port. It may be helpful to disable this feature while troubleshooting. In general, simplifying the network configuration reduces the troubleshooting effort. If configuration changes are made during the troubleshooting effort, note the changes. An alternate way is to save the configuration by maintaining a copy of the configuring in bootflash or on a TFTP server. After the root cause is found and fixed, the removed configurations can be easily reapplied.

The following resources and equipment are required to complete this exercise:

The devices in the network should be connected and ready for use. In this configuration exercise, you will configure and verify some of the features reviewed in this chapter. After completing this exercise, you will be able to do the following:

This exercise assumes that the switches are already configured as required in the configuration exercise found in Chapter 5.

Figure 6-17 shows the network layout for this configuration exercise, which extends upon the topology in Figure 5-34 in Chapter 5. Tasks 1 and 2 only require switches A, B, and C. Task 3 requires the introduction of switch D.

In this configuration exercise, you will use the commands listed in Table 6-4, which are listed in alphabetical order so that you can easily locate the information you need. Refer to this list if you need configuration command assistance during the configuration exercise.

Switch B and switch C have similar output.

The following resources and equipment are required to complete this exercise:

The devices in the network should be connected and ready for use. In this configuration exercise, you will locate and resolve a simulated failure leading to an STP loop. After completing this exercise, you will be able to do the following:

Figure 6-18 shows the network layout for this configuration exercise.

In this configuration exercise, you will use the commands listed in Table 6-5, which are listed in alphabetical order so that you can easily locate the information you need. Refer to this list if you need configuration command assistance during the configuration exercise.