Troubleshooting Bridging Connectivity

This chapter consists of the following sections:

• Transparent Bridging Connectivity Scenario
  

• Creating Network Maps
  

• Bridge-Based Connectivity Symptoms
  

The section on bridge-based connectivity symptoms consists of the following:

• Symptom statement---A specific symptom associated with the bridge connectivity
  

• Possible causes and suggested actions---A table for each symptom containing possible causes for the symptom and suggested actions for resolving each cause
  

Transparent Bridging Connectivity Scenario

Bridge-based internetworks often encounter problems associated with packet looping and conflicts between transparent bridges. The following scenario explores some common problems that can lead to these kinds of connectivity problems in environments that feature transparent bridging over parallel paths.

In this scenario, problems and symptoms that afflict a stable internetwork over a period of time are discussed sequentially. The scenario is split into two parts:

• Scenario Part 1: Problems associated with "spanning tree wars" resulting in no connectivity on the entire internetwork
  

• Scenario Part 2: Problems associated with packet looping and broadcast storms, resulting in excessively high traffic on the internetwork, extremely poor network performance, and, ultimately, blocked communications
  

These two parts are discussed separately. The "Problem Solution Summary" section provided at the end of the scenario addresses both parts.

Figure 6-1 illustrates the basic stable network map for this environment. Assume in this network that all the bridges are configured to use the IEEE spanning tree algorithm and that under normal conditions, T1 Line number 2 is a backup link with Router-B4 in blocking mode. Bridged traffic between the main campus network and the remote network passes over T1 line number 1.

Figure 6-1 : Stable Transparent Bridging Scenario Network Map

Scenario Part 1: Symptoms

After a prolonged period of normal operation, assume that all connectivity on this internetwork suddenly stops. Users are unable to access any network resources, even on the same segment.

Scenario Part 1: Environment Description

The relevant elements of the internetworking environment shown in Figure 6-1 can be summarized as follows:

• LANs are Ethernet-based; the Main Campus Network is interconnected over an FDDI backbone, and the serial link to Remote Network is a dedicated T1 link (1.544 Mbps). A second T1 link provides a backup path.
  

• DECnet is being routed between various VAX hosts; traffic consists of file transfers.
  

• Local area transport (LAT) connection service is provided to a communication server (LAT-A) from a LAT server (VAX-1). LAT is bridged.
  

• All internetworking nodes in this environment are Cisco devices.
  

• All connected bridges are required to run the IEEE spanning tree algorithm.
  

• Bridging node Router-B1 is the spanning tree root bridge by administrative specification.
  

Diagnosing and Isolating Part 1 Problem Causes

In this situation, three problems might explain these connectivity symptoms:

• Unstable media (connected to root bridge)
  

• Unstable internetworking hardware (connected to root bridge)
  

• Excessive traffic
  

In general, it is useful to eliminate the most likely problems first, and then tackle more complex problems as necessary. The problem-solving process that follows illustrates this strategy.

After you identify a possible problem list, you must analyze each potential cause until connectivity is restored. The following discussion considers the list of problems and illustrates resolution of discovered problems.

Eliminating Excessive Traffic as the Problem

In this case, up until the network failure, traffic was normal. That is, users were able to make connections and despite occasionally slow service, complaints were minimal. A sign that excessive traffic might be a problem would be consistently degraded service, chronically slow host response, and dropped connections.

To determine whether excessive traffic has been occurring, use the show interfaces command; look for output drops and collisions on Ethernets, or high 5-minute input and output rates and full input and output queues on serial interfaces.

If these underlying symptoms do not appear, you can eliminate excess traffic as the problem.

Diagnosing Unstable Media and Hardware

After eliminating congestion as the problem, the most likely cause is some kind of hardware problem associated with the root bridge or other hardware attached to the root. These problems can result in a spanning tree war as bridges attempt to assert themselves as the root bridge every time a suspect device or bad link causes the root bridge to reset an interface. Diagnose this kind of problem using the steps that follow.

Step 1 Use the show interfaces EXEC command and examine the output for transition and reset counters at the root bridge or at an internetworking device connected to the root bridge. Figure 6-2 illustrates an example display indicating that these counters are incrementing.

Figure 6-2 : Output of the show interfaces Command Illustrating Resets and Transitions

Problems that can cause transition and reset counters to increment include bad modems, bad modem cables, noisy lines, unreliable LAN media, or bad appliques at the bridges.

For information about troubleshooting LAN media in general, refer to Chapter 1, "Troubleshooting Overview." For more information about troubleshooting hardware, refer to Chapter 2, "Troubleshooting Router Startup Problems." For more information about troubleshooting serial lines, refer to Chapter 3, "Troubleshooting Serial Line Problems."

Step 2 After you isolate a hardware problem, replace suspected devices or cables with known working devices or cables.

Step 3 Use the clear counters command at bridges attached to the problem hardware; then use the show interfaces command again to determine whether the carrier transition and reset counters have stopped incrementing. Determine whether connectivity has been restored.

In this case, assume that connectivity is restored. Now, consider the problems discussed in Part 2 of this scenario.

Scenario Part 2: Symptoms

As discussed previously, Figure 6-1 illustrates a stable bridging network. After resolving Part 1, connectivity is reestablished and normal internetwork operations are restored. However, after a period of uninterrupted service, network managers notice that internetwork performance has again declined following increased instances of broadcast storms.

Scenario Part 2: Environment Description

The relevant elements of the internetworking environment are the same as in Part 1. One note regarding this environment is that the network managers had been making modifications to the internetwork and reconfiguring the internetworking devices when symptoms started to occur.

Diagnosing and Isolating Part 2 Problem Causes

Given the situation, there are two likely problems that can explain these connectivity symptoms:

• Mixed spanning tree environment
  

• Multiple bridging domains
  

Diagnosis for these identified possible problems follows.

Diagnosing Mixed Spanning Tree Algorithm Problems

Problems can arise for internetworks in which both IEEE and DEC spanning tree algorithms are used by bridging nodes. These problems are caused by differences in the way the bridging nodes handle spanning tree bridge protocol data unit (BPDU) packets (or hello packets) and in the way they handle data. The following procedure shows you how to determine whether both spanning tree algorithms are running:

Step 1 Use the show interfaces EXEC command to obtain input and output packet count statistics. If these counters increment at an abnormally high rate (with respect to your normal traffic loads), a loop is likely.

Step 2 Use the show span EXEC command on Cisco bridges to determine whether multiple root bridges exist and to determine which spanning tree protocols are being used.

Step 3 If both DEC and IEEE appear, reconfigure bridges so that all use the same spanning tree protocol version. Use the bridge group protocol ieee global configuration command to make this change. Figure 6-3 illustrates the use of this command, as well as other required commands.

Figure 6-3 : Configuration of IEEE Spanning Tree Algorithm

In this scenario, Router-B1, Router-B2, and Router-B3 are found to be running the IEEE spanning tree algorithm, while Router-B4 is inadvertently misconfigured to use the DEC spanning tree version. To resolve this problem, Router-B4 is reconfigured for IEEE. Figure 6-3 illustrates how to configure the IEEE spanning tree algorithm.

The effect of implementing the mixed spanning tree environment in this configuration is outlined in the following discussion and illustrated in Figure 6-4 through Figure 6-6.

• Router-B1 claims to be the IEEE root, while Router-B4 claims to be the DEC root.
  

• Router-B2 and Router-B3 propagate root information on all interfaces for IEEE spanning tree, indicating that Router-B1 is the root. However, Router-B4 drops IEEE spanning tree information regarding IEEE root Router-B1, as shown by Figure 6-4.
  

Figure 6-4 : Router-B4 Drops IEEE Root Information Propagated by Router-B2 and Router-B3

• Meanwhile, Router-B2 and Router-B3 similarly drop DEC root information relayed from Router-B4. (See Figure 6-5.)
  

Figure 6-5 : Router-B2 and Router-B3 Drop DEC Root Information from Router-B4

• The result is that none of the bridges in this internetwork believe that there is a loop. When a broadcast packet is sent on the network, a "broadcast storm" results over the entire internetwork (including the FDDI backbone and other networks attached via Router-B5 and Router-B6), as shown by Figure 6-6.
  

Figure 6-6 : Mixed Spanning Tree Implementation Results in Packet Looping

Although a configuration change is necessary here, it might not be sufficient to reestablish connectivity. Assume that in this case, connectivity is not restored, even when all bridging nodes are reconfigured to use the same spanning tree algorithm.

Diagnosing Multiple Domain Problems

Another configuration problem that results in packet looping is the inappropriate use of the spanning tree "domain" capability of Cisco bridges. The following procedure outlines how to determine whether multiple domains are specified and how to resolve the problem:

Step 1 Use the show span EXEC command on Cisco bridges to determine whether multiple root bridges exist and to ensure that all domain group numbers match for given bridging domains. The key here is that only one path can exist between different bridging domains because bridges in different domains do not exchange spanning tree information.

In this case, assume that Router-B4 was incorrectly specified as belonging to bridge domain number 2, while all other routers are specified to be in the default domain (bridge domain number 0).

Step 2 Change the configurations so that the domain specifications match using the bridge group domain domain-number global configuration command. In this case, Router-B4 is changed to bridge domain number 0.

Figure 6-7 illustrates the use of this command, as well as other required commands.

Figure 6-7 : Modification to Router-B4 Placing It in Bridge Domain 0

Problem Solution Summary

This scenario focused on diagnosing blocked connectivity in internetworks that implement transparent bridging. The following problems were discussed:

• Unstable media or hardware (resulting in spanning tree wars)---Part 1 of this scenario used several router diagnostic tools to illustrate how to identify media and hardware problems that block network connectivity. In this case, the hardware must be tested and replaced if it is out of tolerance.
  

• Router configuration problems with multiple spanning tree implementations and bridge domain specifications, resulting in packet looping---Part 2 of this scenario discussed these two common configuration problems. These problems can result in packet looping and in blocked network connectivity. Simple configuration changes stopped broadcast storms and restored network service.
  

Figure 6-8 provides a complete configuration listing for Router-B4 (obtained using the write terminal command) after changes were made to the type of spanning tree algorithm and to the bridge domain specification.