a forwarding state and a switching loop occurs. A
switching loop is more serious than a routing loop because
unlike low end routers, even a modest switch can forward
broadcast frames at the full line speed. This can fully
saturate a link and further prevent BPDUs from being exchanged.
Thus, the loop is maintained. How is it possible for the switch
to stop receiving BPDUs while the port is up? The most obvious
answer is that the STP has been turned off. Another common
cause is the unidirectional link. A link is considered
unidirectional when: - Links are up on both sides of the
connection.
- Local side is not receiving the packets
sent by remote side.
- Remote side receives packets
sent by local side.
Consider the scenario in Figure
, the arrows indicate the flow of STP BPDUs. During normal
operation, bridge B is designated on the link B-C. Bridge B
sends BPDUs down to C, which is blocking the port. The port is
blocked while C is seeing BPDUs from B on that link. Now,
consider what happens if the link B-C fails in the direction of
C. C will stop receiving traffic from B, but B will still
receive traffic from C. C will stop receiving BPDUs on the link
B-C, and will age the information received with the last BPDU.
This will take up to 20 seconds, depending on the maxAge STP
timer. Once the STP information is aged out on the port, it
will transition from blocking state to listening, learning, and
eventually to forwarding STP state. This will create a
forwarding loop, as there will be no blocking port in the
triangle A-B-C. Packets will cycle along the path (B still
receives packets from C) taking more and more bandwidth until
the links will be filled up completely bringing the network
down. Web Links http://www.cisco.com/warp/customer/
473/spanning_tree1.swf Note: The user must have a valid CCO
account to view this additional information.
Content
4.3 Troubleshooting Switched Ethernet Networks
4.3.2 Troubleshooting STP loops Once an STP
loop has been identified it is important to isolate the reason
behind the loop. One of the first things to check is if the
Spanning Tree Protocol is running on each of the switches. A
switch should only have STP disabled if it is not part of a
physically looped topology. Unless there is a very good reason
for turning STP off, every switch should have STP enabled. The
IOS command to verify STP operation is: Switch#show
spanning-tree It will be clear from the output of the
show spanning-tree command if STP is not running. It is
important to remember that spanning tree operates on a per-vlan
basis by default on Cisco devices (PVST/PVST+) and executing a
show spanning-tree command will report on VLAN 1 only.
Use the show spanning-tree [vlan ID] command to
verify STP operations for other VLANs. Should STP not be
operating, it can be enabled using the spanning-tree vlan
ID command.
Content 4.3
Troubleshooting Switched Ethernet Networks 4.3.3
Preventing STP loops In order to detect the
unidirectional links before the forwarding loop is created,
Cisco designed and implemented the UDLD protocol. UDLD is a
Layer 2 protocol that works with the Layer 1 mechanisms to
determine the physical status of a link. At Layer 1,
autonegotiation takes care of physical signaling and fault
detection. UDLD performs tasks that autonegotiation cannot
perform, such as detecting the identities of neighbors and
shutting down misconnected ports. When UDLD is enabled, it
works with autonegotiation to prevent physical and logical
unidirectional connections from forming and causing other
protocols to malfunction. UDLD works by exchanging protocol
packets between the neighboring devices. In order for UDLD to
work, both devices on the link must support UDLD and have it
enabled on respective ports. Each switch port configured for
UDLD will send UDLD protocol packets containing the port's own
device/port ID, and the neighbor's device/port IDs seen by UDLD
on that port. Neighboring ports should see their own
device/port ID (echo) in the packets received from the other
side. If the port does not see its own device/port ID in the
incoming UDLD packets for a specific duration of time, the link
is considered unidirectional. This echo-algorithm allows
detection of several issues: - Link is up on both sides,
but packets only received by one side.
- Wiring
mistakes, when receive and transmit fibers are not connected to
the same port on the remote side.
Once the
unidirectional link is detected by UDLD, the respective port is
disabled and the following message is printed on the console:
UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port
disabled Port shutdown by UDLD remains disabled until it is
manually reenabled, or until errdisable timeout expires if
configured. The following commands detail configuring UDLD on
Catalyst switches running Cisco IOS. By default, UDLD is
disabled. First, UDLD needs to be enabled globally by issuing
the following command: Switch(config)#udld enable By
default, this command will enable UDLD on all interfaces. UDLD
can be enabled on a specific interface by issuing the following
command: Switch(config-if)#udld enable The
interface command overrides the global configuration command.
UDLD can be verified with the following command: Switch#show
udld interface See Figure for an example of the
output produced. Should it be necessary to override the UDLD
configuration on individual interfaces, this can be
accomplished from the interface configuration mode:
Switch(config)#interface fastethernet 0/12
Switch(config-if)#udld enable In an environment that
supports UDLD, enabling this functionality has the potential to
prevent STP loops and the loss of network connectivity that
results. Cisco recommends that UDLD should be enabled wherever
possible.
Content 4.3 Troubleshooting Switched
Ethernet Networks 4.3.4 Troubleshooting
incorrect STP root configuration Switches have become the
basic building block of even the simplest networks. They form a
seamless replacement for hubs, and come with STP enabled by
default. Link redundancy can be implemented without any switch
configuration being necessary. In fact it is possible to
construct a highly redundant switched network without ever
having heard of the Spanning-Tree Protocol (STP). Poorly
configured Layer 2 designs usually result from a lack of
knowledge of the Spanning Tree Protocol, or a misunderstanding
of its operation. Examine the switched network topology in
Figure . At first glance, it appears to be an efficient
design. A few pings to devices in the network reveals full
connectivity. However, upon closer inspection the traffic flow
in this topology reveals suboptimal traffic patterns. To really
analyze the network topology it is necessary to look at the
spanning tree states of each of the ports. In Figure it is
apparent that the network has unfortunately chosen the
Marketing department switch as the STP root. Spanning tree has
placed the Data Center port leading to the Telephone Sales
Center in a blocking state. Consequently the majority of
traffic must take the longest path to the Data Center. With the
Data Center at one end of the Spanning Tree, the link between
the switch in Reception and Data Center must carry the entire
traffic load of the organization. The symptoms of suboptimal
Layer 2 design are usually those of congestion and are often
only noticed when traffic levels increase. In a worst case, the
following are symptoms of poor Layer 2 design: - Lost
packets
- High latency
- Poor throughput
Troubleshooting suboptimal Layer 2 design can be a
challenge. Traditional tools such as traceroute operate at
Layer 3 and will reveal nothing about the Layer 2 topology. It
is a common error to overlook Layer 2 as the culprit and
incorrectly troubleshoot the higher layers when faced with
congestion caused by poor Layer 2 design. Another common
mistake made by inexperienced network administrators and