|
|
Transparent bridges were first developed at Digital Equipment Corporation (Digital) in the early 1980s. Digital submitted its work to the Institute of Electrical and Electronic Engineers (IEEE), which incorporated the work into the IEEE 802.1 standard. Transparent bridges are very popular in Ethernet/IEEE 802.3 networks
Transparent bridges are so named because their presence and operation are transparent to network hosts. When transparent bridges are powered on, they learn the network's topology by analyzing the source address of incoming frames from all attached networks. If, for example, a bridge sees a frame arrive on line 1 from Host A, the bridge concludes that Host A can be reached through the network connected to line 1. Through this process, transparent bridges build a table such as the one in Figure 20-1.
Transparent bridges successfully isolate intrasegment traffic, thereby reducing the traffic seen on each individual segment. This usually improves network response times as seen by the user. The extent to which traffic is reduced and response times are improved depends on the volume of intersegment traffic relative to the total traffic as well as the volume of broadcast and multicast traffic.
Without a bridge-to-bridge protocol, the transparent bridge algorithm fails when there are multiple paths of bridges and local-area networks (LANs) between any two LANs in the internetwork. Figure 20-2 illustrates such a bridging loop.
Suppose Host A sends a frame to Host B. Both bridges receive the frame and correctly conclude that Host A is on Network 2. Unfortunately, after Host B receives two copies of Host A's frame, both bridges again receive the frame on their Network 1 interfaces because all hosts receive all messages on broadcast LANs. In some cases, the bridges will then change their internal tables to indicate that Host A is on Network 1. If this is the case, when Host B replies to Host A's frame, both bridges receive and subsequently drop the replies because their tables indicate that the destination (Host A) is on the same network segment as the frame's source.
In addition to basic connectivity problems such as the one just described, the proliferation of broadcast messages in networks with loops represents a potentially serious network problem. Referring again to Figure 20-2, assume that Host A's initial frame is a broadcast. Both bridges will forward the frames endlessly, using all available network bandwidth and blocking the transmission of other packets on both segments.
A topology with loops such as that shown in Figure 20-2 can be useful as well as potentially harmful. A loop implies the existence of multiple paths through the internetwork. A network with multiple paths from source to destination can increase overall network fault tolerance through improved topological flexibility.
The STA designates a loop-free subset of the network's topology by placing those bridge ports that, if active, would create loops into a standby (blocking) condition. Blocking bridge ports can be activated in the event of primary link failure, providing a new path through the internetwork.
Figure 20-3 illustrates how the STA eliminates loops. The STA calls for each bridge to be assigned a unique identifier. Typically, this identifier is one of the bridge's Media Access Control (MAC) addresses plus a priority. Each port in every bridge is also assigned a unique (within that bridge) identifier (typically, its own MAC address). Finally, each bridge port is associated with a path cost. The path cost represents the cost of transmitting a frame onto a LAN through that port. In Figure 20-3, path costs are noted on the lines emanating from each bridge. Path costs are usually default values, but they can be assigned manually by network administrators.
The first activity in spanning-tree computation is the selection of the root bridge, which is the bridge with the lowest-value bridge identifier. In Figure 20-3, the root bridge is Bridge 1. Next, the root port on all other bridges is determined. A bridge's root port is the port through which the root bridge can be reached with the least aggregate path cost. The value of the least aggregate path cost to the root is called the root path cost.
Finally, designated bridges and their designated ports are determined. A designated bridge is the bridge on each LAN that provides the minimum root path cost. A LAN's designated bridge is the only bridge allowed to forward frames to and from the LAN for which it is the designated bridge. A LAN's designated port is the port that connects it to the designated bridge.
In some cases, two or more bridges can have the same root path cost. For example, in Figure 20-3, Bridges 4 and 5 can both reach Bridge 1 (the root bridge) with a path cost of 10. In this case, the bridge identifiers are used again, this time to determine the designated bridges. Bridge 4's LAN V port is selected over Bridge 5's LAN V port.
Using this process, all but one of the bridges directly connected to each LAN are eliminated, thereby removing all two-LAN loops. The STA also eliminates loops involving more than two LANs, while still preserving connectivity. Figure 20-4 shows the results of applying the STA to the network shown in Figure 20-3. Figure 20-4 shows the tree topology more clearly. Comparing this figure to the pre-spanning-tree figure shows that the STA has placed both Bridge 3's and Bridge 5's ports to LAN V in standby mode.
The spanning-tree calculation occurs when the bridge is powered up and whenever a topology change is detected. The calculation requires communication between the spanning-tree bridges, which is accomplished through configuration messages (sometimes called bridge protocol data units, or BPDUs). Configuration messages contain information identifying the bridge that is presumed to be the root (root identifier) and the distance from the sending bridge to the root bridge (root path cost). Configuration messages also contain the bridge and port identifier of the sending bridge and the age of information contained in the configuration message.
Bridges exchange configuration messages at regular intervals (typically one to four seconds). If a bridge fails (causing a topology change), neighboring bridges soon detect the lack of configuration messages and initiate a spanning-tree recalculation.
All transparent bridge topology decisions are made locally. Configuration messages are exchanged between neighboring bridges. There is no central authority on network topology or administration.
The IEEE 802.1d configuration message format is shown in Figure 20-5.
The fields of the transparent bridge configuration message are as follows:
Topological change messages consist of only 4 bytes. They include a protocol identifier field, which contains the value 0; a version field, which contains the value 0; and a message type field, which contains the value 128.
The following sections describe the most common network problems in transparent bridged networks:
Symptom: Client cannot connect to hosts across a transparently bridged network.
Table 20-1 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Causes | Suggested Actions |
|---|---|
Hardware or media problem | Step 1 Use the show bridge exec command to see whether there is a connectivity problem. If there is, the output will not show any MAC1 addresses in the bridging table. Step 2 Use the show interfaces exec command to determine whether the interface and line protocol are up. Step 3 If the interface is down, troubleshoot the hardware or the media. Refer to "Troubleshooting Hardware and Booting Problems." Step 4 If the line protocol is down, check the physical connection between the interface and the network. Make sure that the connection is secure and that cables are not damaged. If the line protocol is up but input and output packet counters are not incrementing, check the media and host connectivity. Refer to the media troubleshooting chapter that covers the media type used in your network. |
Step 1 Check whether bridges are communicating with one another. Use a network analyzer or the debug spanning-tree privileged exec command to see whether spanning-tree hello frames are being exchanged. Caution: Exercise caution when using the debug spanning-tree command. Because debugging output is assigned high priority in the CPU process, it can render the system unusable. For this reason, use debug commands only to troubleshoot specific problems or during troubleshooting sessions with Cisco technical support staff. Moreover, it is best to use debug commands during periods of lower network traffic and fewer users. Debugging during these periods decreases the likelihood that increased debug command processing overhead will affect system use. Step 2 If hellos are not being exchanged, check the physical connections and software configuration on bridges. | |
Misconfigured bridging filters | Step 1 Use the show running-config privileged exec command to determine whether bridge filters are configured. Step 2 Disable bridge filters on suspect interfaces and determine whether connectivity returns. Step 3 If connectivity does not return, the filter is not the problem. If connectivity is restored after removing filters, one or more bad filters are causing the connectivity problem. Step 4 If multiple filters or filters using access lists with multiple statements exist, apply each filter individually to identify the problem filter. Check the configuration for input and output LSAP2 and TYPE filters, which can be used simultaneously to block different protocols. For example, LSAP (F0F0) can be used to block NetBIOS and TYPE (6004) can be used to block local-area transport. Step 5 Modify any filters or access lists that are blocking traffic. Continue testing filters until all filters are enabled and connections still work. |
Excessive multicast or broadcast traffic can cause input and output queues to overflow, resulting in dropped packets. Step 1 Use the show interfaces command to look for input and output drops. Drops suggest excessive traffic over the media. If the current number of packets on the input queue is consistently at or greater than 80% of the current size of the input queue, the size of the input queue may require tuning to accommodate the incoming packet rate. Even if the current number of packets on the input queue never seems to approach the size of the input queue, bursts of packets may still be overflowing the queue. Step 2 Reduce broadcast and multicast traffic on attached networks by implementing bridging filters, or segment the network using more internetworking devices. Step 3 If the connection is a serial link, increase bandwidth, apply priority queuing, increase the hold queue size, or modify the system buffer size. For more information, refer to "Troubleshooting Serial Line Problems." | |
Host is down | Step 1 Use the show bridge exec command on bridges to make sure that the bridging table includes the MAC addresses of attached end nodes. The bridging table comprises the source and destination MAC addresses of hosts and is populated when packets from a source or destination pass through the bridge. Step 2 If any expected end nodes are missing, check the status of the nodes to verify that they are connected and properly configured. Step 3 Reinitialize or reconfigure end nodes as necessary and reexamine the bridging table using the show bridge command. |
| 1MAC = Media Access Control 2LSAP = Link Service Access Point |
Symptom: Connections in a transparently bridged environment are successfully established, but sessions sometimes terminate abruptly.
Table 20-2 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Causes | Suggested Actions |
|---|---|
Excessive retransmissions | Step 1 Use a network analyzer to look for host retransmissions. Step 2 If you see retransmissions on slow serial lines, increase the transmission timers on the host. For information on configuring your hosts, refer to the vendor documentation. For information on troubleshooting serial lines, refer to "Troubleshooting Serial Line Problems." If you see retransmissions on high-speed LAN media, check for packets sent and received in order, or dropped by any intermediate device such as a bridge or switch. Troubleshoot the LAN media as appropriate. For more information, refer to the media troubleshooting chapter that covers the media type used in your network. Step 3 Use a network analyzer to determine whether the number of retransmissions subsides. |
Excessive delay over serial link | Increase bandwidth, apply priority queuing, increase the hold queue size, or modify the system buffer size. For more information, refer to "Troubleshooting Serial Line Problems." |
If there are multiple root bridges in the network, the root of the spanning tree can periodically change, causing connections to drop. Step 1 Use a network analyzer to find out whether there are multiple root bridges. You can also use the show span exec command on each bridge to see whether a bridge is a root bridge. Step 2 If there are multiple root bridges in the network, eliminate the extraneous root bridges. Use the bridge group priority number command on root bridges to force the desired bridge to become the root. The lower the priority, the more likely the bridge is to become the root. |
Symptom: Packet looping and broadcast storms occur in transparent bridging environments. End stations are forced into excessive retransmission, causing sessions to time out or drop.
Table 20-3 outlines the problems that might cause this symptom and describes solutions to those problems.
| Possible Causes | Suggested Actions |
|---|---|
Step 1 Examine a topology map of your internetwork to check for possible loops. Step 2 Eliminate any loops that exist or make sure that the appropriate links are in backup mode. Step 3 If broadcast storms and packet loops persist, 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 probably still present in the network. Step 4 Implement a spanning-tree algorithm to prevent loops. | |
Spanning-tree algorithm mismatch | Step 1 Use the show span exec command on each bridge to determine which spanning-tree algorithm is being used. Step 2 Make sure that all bridges are running the same spanning-tree algorithm (either DEC or IEEE)1. If both DEC and IEEE algorithms are being used, reconfigure bridges as appropriate so that all bridges use the same spanning-tree algorithm. Note: The DEC and IEEE spanning-tree algorithms are incompatible. |
Step 1 Use the show span exec command on bridges to ensure that all domain group numbers match for given bridging domains. Step 2 If multiple domain groups are configured for the bridge, ensure that all domain specifications are assigned correctly. Use the bridge group domain domain-number global configuration command to make any necessary changes. Step 3 Make sure that no loops exist between bridging domains. An interdomain bridging environment does not provide loop prevention based on spanning tree. Each domain has its own spanning tree, which is independent of the spanning tree in another domain. |
| 1IEEE = Institute of Electrical and Electronic Engineers |
Posted: Tue May 16 15:14:14 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.