by Martin Bligh
This chapter provides an overview of bridges and the way that they work, covering both transparent and source route bridging. The spanning tree algorithm is also explained--this is the basis of the way that transparent bridges are controlled.
Bridges, which operate at the data link layer, connect two LANs (local area networks) together, and forward frames according to their MAC (media access control) address (see Figure 7.1). Often the concept of a router is more familiar than that of a bridge; it may help to think of a bridge as a "low-level router" (routers operate at the network layer, forwarding by addresses such as an IP address).
FIGURE 7.1. Where connecting devices fit into the OSI stack.
A remote bridge connects two remote LANs (bridge 1 and 2 in Figure 7.2) over a link that is normally slow (for example, a telephone line), while a local bridge connects two locally adjacent LANs together (bridge 3 in Figure 7.2). With a local bridge, performance is an issue, but for a remote bridge, the capability to operate over a long connecting line is often more im-portant.
FIGURE 7.2. A sample network with local and remote bridges.
Bridges do not know about the higher level protocols inside the frames that they forward. This means that they will deal with IP, IPX, and so on all at the same time (and in a consistent manner) together with any new protocols that come along. Bridges also provide a way to segment networks that are using nonroutable protocols, such as NetBEUI.
The fact that routers deal with data at the network level means that it is much easier for them to interconnect different data-link layers, such as connecting a Token Ring segment to an Ethernet segment.
Bridges are often more difficult to control than routers. Protocols such as IP have highly sophisticated routing protocols associated with them, allowing the network administrator to exercise tight control over routing. Protocols such as IP also provide more information about how networks should be logically segmented (even in the addresses themselves). Bridges are inherently more difficult to control--they only have the MAC address and the physical topology to work with. For this reason, bridges are generally more suitable for smaller, simpler networks.
There are two main types of bridge:
These different types of bridge will now be examined in detail.
Transparent bridges are mostly used to interconnect Ethernet segments. The bridge passes traffic that needs to go between different segments, but isolates traffic that is local to the segment on which it is received. The bridge thus reduces the total amount of traffic on the network.
Bridges have two or more interfaces to the network--each of these is called a port.
This section describes bridge operation when there are no loops in the network and there is only one path between any two given hosts.
The bridge is called transparent because it appears to all hosts on the network as though it is not there. As far as the network layer (IP for example) is concerned, all networks connected by a bridge might as well be physically connected.
How is this transparency maintained? The "default" action for a bridge is to forward any received frame. The only situation where frames will not be forwarded is when the bridge knows that the destination host is connected via the same bridge port as the source host (for example, if a frame is received on port 1 that is also destined to go out only on port 1). Fortunately, the bridge can use this rule to eliminate the forwarding of many frames.
For each of the bridge's ports, a list of MAC addresses connected to that port is maintained. The bridge knows that host G is connected to port 3 if it receives a frame from host G on port 3. In case hosts move their position on the network, each entry in this list has a TTL (time to live) associated with it, and it will expire after a set time. Whenever a frame is received from that MAC address, the TTL for the relevant entry will be reset.
The simplest bridge configuration is one bridge connecting two subnets. In Figure 7.3, the bridge should forward frames from host A to host C, but not from host A to host B.
However, in the initial learning phase, the situation is not quite as simple. Imagine that the bridge has just been turned on. All of its data tables are empty--it does not know where any other hosts are. The bridge's tables through an initial packet sequence might be as follows:
FIGURE 7.3. The simplest bridged network.
The simple transparent bridge described in the previous section will function well, even with a much more complex network with many bridges. However, when loops in the network or multiple paths between any two points are created, the model breaks down. In Figure 7.4, a network is shown with two bridges, both connecting two subnets together, and thereby creating a loop. This type of design would be useful to create redundancy, in case one of the bridges fails.
FIGURE 7.4. A small bridged network with a loop.
Now imagine the following situation: All bridge tables are empty to start with, and host A sends a frame to host B (transmission 1 on the diagram).
It is clear that a loop has been created, along with a large amount of unnecessary traffic. Worse still, there are two packets going around in circles for each packet sent, and the bridges tables are being continuously updated.
The problem is caused by the presence of more than one bridge forwarding traffic between the same two subnets, and this is clearly an unacceptable situation. The chosen way to resolve this problem is the "Spanning Tree Algorithm" defined by IEEE 802.1d.
Figure 7.5 shows a complex network with many bridges--each network is represented as a cloud marked LAN, and each bridge link is represented by an arrow.
FIGURE 7.5. A complex network with several loops, showing a spanning tree.
When all the arrows are used, loops can be seen. The black arrows form a spanning tree by using a subset of the links. Notice that all nodes are directly or indirectly connected to each other, but there are no loops. This is the definition of a spanning tree.
Spanning trees are not always unique. Given sufficient redundancy in the network, it is normally possible to draw a different spanning tree. A resilient network design will ensure that it is possible to draw a spanning tree in the absence of any given link. The paranoid (or the military) may try to achieve a network that contains a spanning tree despite the absence of any two links (or more!). Figure 7.6 shows an alternative spanning tree.
FIGURE 7.6. The complex network, showing an alternative spanning tree.
Compare Figures 7.5 and 7.6, noting the similarities and the differences. Both have eight black arrows to link their nine networks. It turns out that it is fairly easy to prove mathematically (graph theory) that a spanning tree always requires one fewer link than the number of networks it is connecting.
It is also easy to see that a completely different set of three links are gray between the two diagrams. In fact, there is no single link in the diagram that could be turned gray (that is, broken), which would prevent us from drawing a spanning tree (or in other words, interconnecting the networks).
It can be proven mathematically that given any set of networks that are connected to one another, it is possible to find a subset of the links that form a spanning tree (that is, a set that still connects all the networks, but with no loops).
Now that you know a subset of the bridged links exists that will allow any network to operate without loops (a spanning tree), how do the bridges determine a spanning tree and decide which spanning tree to use?
Bridges communicate via messages called Bridge Protocol Data Units (BPDUs). Before the bridges in the network can make sensible decisions about how to configure themselves, each bridge and each port need some configuration data:
Having configured each bridge, the bridges will automatically determine a spanning tree to use. The configuration parameters that you have set will determine which spanning tree is chosen.
There are three stages in determining the spanning tree:
FIGURE 7.7. A bridged network showing root and designated ports.
Note that a port must be one (and only one) of the following:
Note that a root port is never a designated port for a LAN (in Figure 7.7, port 7 on bridge 3 is not the designated port for LAN E, for example). The root port is a path to the root bridge, so there must be another bridge closer to the root bridge attached to this LAN (in this case, bridge 2). This other bridge would therefore be the designated bridge for the LAN, and would hold the designated port (port 6).
When a bridge is switched on, it assumes that it is the root bridge. The bridge transmits a configuration bridge protocol data unit (CBPDU), stating the bridge ID of the bridge it perceives to be the root bridge.
A bridge receiving a CBPDU frame with a lower bridge ID than its known root bridge will update its tables. If the frame was received upon the bridge's root port (upstream), the information is disseminated to all designated ports (downstream).
If the given bridge ID is higher that its known root bridge, the information will be discarded. If the frame was received on a designated port (downstream), a reply is sent, containing the lower bridge ID of the real root bridge.
If the network is reconfigured, either deliberately or due to a link failure, the process will be repeated, and a new spanning tree decided upon.
Source routing bridges operate on a different principle than transparent bridges. Transparent bridges present the illusion of one continuous network segment to the connected hosts. Source route bridges do not make any decisions about where to forward packets, and do not build up lists of host MAC addresses.
Though the principle of routing is different, source route bridges must still be configured with identification information. Each bridge is given a unique number (the bridge ID). Each LAN (Token Ring) is also given a unique identifier (the ring ID). This can be seen clearly in Figure 7.8. Note that some bridges use different bases for identifiers (that is, some are in hexadecimal, and some are in decimal).
Any station wishing to send a frame to a station on a remote network must specify which bridges the frame should traverse. For instance in Figure 7.8, if host A wishes to send a frame to host D, it could specify:
A -> TR1 -> B2 -> TR3 -> B7 -> TR5 -> D
or ...
A -> TR1 -> B4 -> TR4 -> B8 -> TR5 -> D
or any of a number of other possible routes.
There is not always such a large choice of routes--the network in Figure 7.8 is highly robust, providing a large number of alternative routes. In a simpler network, there might only be one available route. The choice of which route to use is strictly the responsibility of the sending host.
What would transparent bridging do with this network? The spanning tree algorithm would force some of the bridge ports to be blocked. You might well end up with a spanning tree where bridges 1, 4, 5, and 8 are totally redundant (until a failure occurs). However, this would put a massive load on Token Ring 3. With source route bridging, a more flexible routing scheme can be achieved at the cost of the hosts managing all the routing information.
The IEEE 802.5 standard for Token Ring defines several fields of interest in the frame header. The I/G bit at the head of the source address is set if routing information is present in the frame. The route itself is defined in the routing information section as a list of 2-byte route designators.
FIGURE 7.8. A bridged network showing root and designated ports.
If the stations are to specify the path to be taken to the remote host, they must have a way of finding the path. This function is performed by sending out path discovery messages. Path discovery need not be performed for each packet sent, but rather the path information is cached and reused.
The transmitting host sends out an All Routes Explorer (ARE) frame with a blank list of route designators. Each bridge receiving the frame adds the bridge ID and the network ID to the list of route designators, and forwards the frame to all ports other than the port on which it was received.
The receiving host will receive one ARE frame for each possible route, from the transmitter to the receiver. For each ARE frame arriving at its destination, an SRF (specified route frame) is sent in reply to the original host. A path to the destination is then chosen by the original host.
The Spanning Tree Explorer (STE) frame relies upon a spanning tree being defined. An STE frame is broadcast from the originating host, which is passed across a spanning tree by the bridge network (see the previous section on spanning trees). This means that exactly one copy of the STE frame will arrive at each LAN on the network. The destination host will therefore receive only one copy of the STE frame, with a copy of the route taken in it. The destination host responds with an ARE frame to the originating host.
Source route bridges put the requirement on the host to determine all the routing information and route discovery. This means that more traffic is generated by routing information--assuming there are more hosts than bridges on the network!
Transparent bridges require no input from the host, and therefore no modifications to the network stack. However, the set of paths used are often suboptimal. The method used to avoid loops is simply to disable some ports!
Bridges operate at the data link layer, allowing them to be independent of the network layer protocols being used. There are two main types of bridges: transparent bridges and source routing bridges. Transparent bridges make decisions about frame routing for themselves and are most commonly found on Ethernet networks. Source route bridges rely on the host for routing decisions, and are most commonly found on Token Ring networks.
© Copyright, Macmillan Computer Publishing. All rights reserved.
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}
){kind=link}