LANs to WANs(c) The Complete Management Guide
Authors: Muller N.J.
Published year: 2003
|< Day Day Up >|
Depending on the situation facing network managers, bridges can be used to either extend or segment LANs. At one level, bridges can be used for segmenting LANs into smaller subnets to improve performance, control access, and facilitate fault isolation and testing without impacting the overall user population. At another level, they are used to create an extended network that greatly expands the number of devices that can be supported and the services available to each user . Bridges may even offer additional features such as data compression, which has the effect of providing greater throughput over low-speed lines. Compression ratios of 2:1 all the way down to 6:1 may be selected by the network manager, depending on what the vendor offers with a specific product.
As noted, bridging occurs at the data link layer (see Figure 5.1), which provides physical addressing, manages access to the physical medium, controls data flow, and handles transmission errors. Bridges analyze incoming frames, make forwarding decisions based on the source and destination addresses of those frames, and then forward the frames to their destinations. Sometimes, as in source-route bridging, the frame contains the entire path to the destination. In other cases, as in transparent bridging, frames are forwarded one hop at a time toward the destination.
Figure 5.1: Bridge functionality in reference to the OSI model.
Bridges can be either local or remote. Local bridges provide direct connections between many LAN segments in the same area. Remote bridges connect LAN segments in different areas, usually over telecommunication lines. There are several kinds of bridging and all may be supported in the same device:
Transparent bridging —used mostly in Ethernet environments that have the same media types, these bridges keep a table of destination addresses and outbound interfaces.
Source-route bridging —used mostly in token-ring environments, these bridges only forward frames based on the routing indicator contained in the frame. End stations are responsible for determining and maintaining the table of destination addresses and routing indicators.
Translation bridging —used to bridge data between different media types, these devices typically go between Ethernet and FDDI or token ring to Ethernet.
Source-route translation bridging —this is a combination of source-route bridging and transparent bridging that allows communication in mixed Ethernet and token-ring environments. (Translation bridging without routing indicators between token ring and Ethernet is also called source-route transparent bridging.)
The engine for transparent bridging is the spanning tree algorithm (STA), which dynamically discovers a loop-free subset of the network’s topology. The STA accomplishes this by placing active bridge ports that create loops into a standby or blocked condition. A blocked port can provide redundancy in that if the primary port fails, it can be activated to take the traffic load.
The spanning tree calculation is triggered when the bridge is powered up and whenever a change in topology is detected . A topology change might occur when a forwarding port is going down (blocking) or when a port transitions to forwarding and the bridge has a designated port, which also indicates that the bridge is not standalone. Configuration messages known as bridge protocol data units (BPDUs) actually trigger the spanning tree calculation. These messages are exchanged between bridges at regular intervals set by the network manager, usually 1 to 4 seconds.
Once a change in topology is detected, this information must be shared with all bridges on the network. This is a two-step process that starts when a bridge notifies the root bridge of the spanning tree by sending it a special BPDU known as a topology change notification (TCN). The bridge sends the TCN out over its root port. The root bridge acknowledges the message by sending back a normal configuration BPDU with the topology change acknowledgment (TCA) bit set. The second step in the topology update process entails the root bridge sending out configuration BPDUs with the topology change (TC) bit set. These BPDUs are relayed by every bridge, so they can become aware of the changed topology.
There are some problems associated with spanning tree. The more hosts on the network, the higher the probability of topology changes. For example, a directly attached host, such as a client or server, will trigger a topology change when powered off, then go on to clear an operating system problem. In a large, flat network, the point can be reached when it is continually in topology change status. The resulting high level of flooding can lead to an unstable STP environment. To deal with this problem, vendors have come up with ways to avoid TCN generation for certain events. For example, the network manager can configure the bridge so that it issues a TCN when a server is power cycled, but not when client devices are power cycled. If a bridge port going up or down is not deemed an important event, this event too can be programmed not to issue a TCN.
Source-route bridging (SRB) is used in the token-ring environment as the method by which a station establishes a route through a multiple-ring network to its destination. The first step for a station to reach another is to create a packet called an explorer. This packet is copied by all bridges in the network, with each of them adding information about itself before passing it on. The explorer packet’s routing information field (RIF) contains the information of where it has traversed through the network and within the RIF; a route descriptor stores the path it has taken through the network.
As the explorer packet is constructed on its way through the network, the destination station will start receiving data packets from the originating station. Based on the contents of the explorer packet, the destination station will then decide which route to use to send data packets back to the originating station. Or it will send its own explorer packet so that the originating station can determine its own route.
The explorer packet is limited in terms of how many rings it can hold in the routing information field. Although the RIF can hold a total of 14 rings, IBM long ago limited this to seven. Other vendors also adopted this limitation. Consequently, an explorer packet that has traversed seven rings will be dropped in the network. To control traffic in the network with more precision, parameters can be set in the bridge to decrease this number even further, so that packets that reach X number of rings (any number below seven) will be dropped.
While explorers are limited to traversing only seven rings, in a meshed ring environment, one explorer can finish being copied by many bridges, which can cause too many explorers. Explorer storms can be prevented in redundant network topologies by setting the bridge to filter out explorers that have already been forwarded once. Since explorer traffic can be distinguished from regular source route traffic, the network manager can issue commands that check the bridge for various parameters, such as the number of explorers that were dropped outbound on that interface.
While Ethernet has become the network of choice for new installations, there is still a good amount of token ring in use, making it necessary to mix the two environments for data exchange. Doing so is complicated because some very fundamental differences between Ethernet and token ring must be reconciled. Token ring has functional addresses, while Ethernet primarily relies on broadcasts.
Furthermore, MAC addresses on the Ethernet are different from MAC addresses on the token ring. Ethernet does not have a source-route bridging capability and token ring has a routing information field. Finally, token ring and Ethernet use different methods to read the bits into their adapters.
To unify the two environments, vendors have come up with various methods such as translation bridging. This is a type of bridging that is implemented on networks that use different MAC sublayer protocols, providing a method of resolving differences in header formats and protocol specifications. Since there are no real standards in how communication between two media types should occur, however, no single translation implementation can be called correct. The only consideration for network managers is to select a method of translation and implement it uniformly throughout the network.
Essentially, the bridges reorder source and destination address bits when translating between Ethernet and token-ring frame formats. The problem of embedded MAC-addresses can be resolved by programming the bridge to look for various types of MAC addresses. Some translation-bridges simply check for the most popular embedded addresses. If others are used, the bridge must be programmed to look for them as well. But if translation-bridging software runs in a multi-protocol router, which is very common today, these protocols can be routed and the problem avoided entirely.
Token ring’s RIF field has a component that indicates the largest frame size that can be accepted by a particular source-route bridging implementation. Translation bridges that send frames from the transparent-bridging domain to the SRB domain usually set the maximum transfer unit (MTU) field to 1,500 bytes to limit the size of token-ring frames entering the transparent-bridging domain, because this is the maximum size of Ethernet frames. Some hosts cannot process this field correctly, in which case translation bridges are forced to drop the frames that exceed Ethernet’s MTU size.
Bits representing token-ring functions that are absent in Ethernet are discarded by translation bridges. For example, token ring’s priority, reservation, and monitor bits are discarded during translation. And token ring’s frame status bits are treated differently, depending on the bridge manufacturer; the products of some manufacturers may even ignore these bits.
Sometimes, the bridge will have the C bit set, indicating that the frame has been copied, but not the A bit set, indicating that the destination station recognizes the address. In the former case, a token-ring source node determines if the frame it sent has become lost. Advocates of this approach claim that reliability mechanisms, such as the tracking of lost frames, are better left for implementation in Layer 4 of the OSI model. Advocates of setting the C bit argue that this bit must be set to track lost frames, but that the A bit cannot be set because the bridge is not the final destination.
Translation bridges also can be used to create a software gateway between the token ring and Ethernet domains. To the SRB end stations, the translation bridge has a ring number and a bridge number associated with it, so it looks like a standard source-route bridge. In this case, the ring number reflects the entire transparent-bridging domain. To the transparent-bridging domain, the translation bridge is just another transparent bridge.
When bridging from the SRB domain to the transparent-bridging domain, SRB information is removed. Token ring’s routing information fields usually are cached for use by any subsequent return traffic. When bridging from the transparent bridging to the SRB domain, the translation bridge checks the frame to see if it has a multicast or unicast destination. If the frame has a multicast or broadcast destination, it is sent into the SRB domain as a spanning-tree explorer. If the frame has a unicast address, the translation bridge looks up the destination in the RIF cache. If a path is found, it is used and the RIF information is added to the frame; otherwise , the frame is sent as a spanning-tree explorer.
Another solution to unify the Ethernet and token-ring environments is source-route translation bridging (SRTLB). This entails the addition of bridge groups to the interfaces of both the token ring and Ethernet bridges to create a transparent bridge domain between the two environments. The bridges at each end are responsible for establishing the path through the network. When a bridge on a token ring receives a packet from an Ethernet, for example, path establishment is handled as follows (see Figure 5.2):
Figure 5.2: Source-route translation bridging, from token ring to Ethernet.
Bridge-1 receives a packet from the Ethernet. This is from PC-1 to the host.
Bridge-1 needs a RIF to reach the host, so it creates an explorer to learn the path to reach the host.
After Bridge-1 receives the response, it sends the response (without a RIF) to the Ethernet station.
PC-1 sends an exchange identifier (XID) to the host MAC address.
Bridge-1 gets the Ethernet packet, attaches the RIF to the host, and sends the packet on its way.
As far as the host is concerned , the Ethernet is sitting on a pseudo ring. This is configured with the source-bridge transparent command on the bridge. The pseudo ring makes the host treat the Ethernet as if it were a token ring.
|< Day Day Up >|
LANs to WANs(c) The Complete Management Guide
Authors: Muller N.J.
Published year: 2003