Bridge Technology Basics
One common cause of confusion in the networking world is the difference between a bridge and a router, and the difference in the expected behavior of each. This essay will outline the reasons bridges were created, define the expected behavior of a bridge, and finally, will close with a concise definition of a bridge.
For a much more detailed treatment of the material in these essays Savvius recommends Radia Perlman’s book “Interconnections – Bridges and Routers,” which is available from Addison-Wesley, ISBN number 0-201-56332-0.
Why Use Bridges?
As anyone with networking experience knows, segmenting a large network with an interconnect device has numerous benefits. Among these are reduced collisions (in an Ethernet network), contained bandwidth utilization, and the ability to filter out unwanted packets. However, if the addition of the interconnect device required extensive reconfiguration of stations, the benefits of the device would swiftly be outweighed by the administrative overhead required to keep the network running. Bridges were created to allow network administrators to segment their networks transparently. What this means is that individual stations need not know whether there is a bridge separating them or not. It is up to the bridge to make sure that packets get properly forwarded to their destinations. This is the fundamental principle underlying all of the bridging behaviors we will discuss.
It should be noted that IBM invented a second type of non-transparent bridge, called a source-routing bridge. These are emphatically not the types of bridges we’re discussing here.
- Transparent Bridges: A bridge is said to be “transparent” because a transmitting station addresses frames directly to the DLC address of the destination station. This section discusses this concept of “transparency”.
The Concept Of “Transparency”
When a NIC (Network Interface Card) receives a valid packet, the normal behavior is for the NIC to check to see if the Destination DLC Address in the packet is one that it has been configured to recognize. If the destination DLC Address is one that the NIC has been configured to recognize, then the packet is passed up to the next higher layer of processing.
Bridges, on the other hand, listen to the network in promiscuous mode, meaning that they accept all packets, regardless of the packets’ addressing. On a side note, this promiscuous mode is the same thing that allows your network analyzer to capture all the packets going across the network. The bridge then looks up each packet’s Destination DLC Address in its internal tables to find out which port the Destination NIC is attached to. Finally, it forwards the packet onto only the necessary port. In the case of a broadcast message, the bridge forwards the packet onto every port except the port that the packet came in on. Promiscuous listening is the key to the bridge’s transparent operation. Since the bridge effectively “hears” all packets that are transmitted, it can decide whether forwarding is necessary without any special behavior from the individual stations.
Examples Of Transparent Bridging Behavior
Take, for example, a simple network consisting of a four-port transparent bridge with five stations attached to it. The ports on the bridge shall be numbered one through four, with Station A and Station B on port 1, no station on port 2, Station C on port 3, and Station D and Station E on port 4. (see Fig. 1). If you are using a non-graphical browser, it may help to draw this out on paper.
What happens when Station A transmits a packet destined for Station C? The bridge, which is listening in promiscuous mode, examines its internal tables (let’s not worry about how the data gets into the internal tables just yet) and determines that Station C is attached to port 3. It then forwards the packet only onto port 3. (see Fig. 2). Consider what will happen if Station D tries to send a packet to Station E while this is going on. With the bridge, there will be no traffic on segment 4, and the conversation will proceed. If there were no bridge, Station D would not be able to send because Station A would have access to the media.
If Station A transmits a packet that is destined for a station that is on the same port as Station A, for example, Station B, the bridge will realize that there is no reason for it to forward the packet onto any of its ports (see Fig. 3).
If a Station, for example, Station B, transmits a broadcast or multicast packet, the bridge will forward the packet onto all ports (see Fig. 4).
Definition Of A “Bridge”
So, to sum up, here is a concise definition of a transparent bridge:
A bridge is a device that operates at the Data Link Layer of the OSI model. It selectively forwards frames based on an examination of the Data Link Layer addresses in the frames. Any device that fits this description is acting as a transparent bridge.
(This means that a Layer 2 Switch is, essentially, performing a bridging function. Switches are discussed in the Switch Technology section)
This definition has an important implication: A bridge doesn’t care what upper layer protocols are being used. A bridge will forward packets correctly whether they are NetWare, TCP/IP, AppleTalk, or even DECnet. As long as the bridge has the right kind of NIC (Ethernet, Token Ring, FDDI, etc…) it can forward properly. Because of this quality, bridges are said to be protocol independent.
- Learning Bridges: This section describes the technology used in Learning Bridges. The alternative to a Learning Bridge is a Source Route Bridge.
Bridges Learn Where Destination Stations Are Located
So, as discussed in the previous essay, a transparent bridge examines a packet’s Destination Data Link Address and looks up the Address in its internal tables to determine which of its ports, if any, to forward the packet onto. In this essay, we will discuss exactly how the bridge’s internal tables get filled.
A learning bridge can be added to a network, and it will learn the network topology without help from humans. If a station is moved, the bridge will realize it and update its tables appropriately. Originally, there were some transparent bridges that did not have learning capability, but today, the terms “transparent bridge” and “learning bridge” are used interchangeably.
The Learning Algorithm
A learning bridge tracks Source Addresses. Because it knows what ports different addresses come from, it knows onto what port to send packets going to those addresses. The Learning Algorithm can be written in PseudoCode as follows:
If the address is in the tables then
Forward the packet onto the necessary port.
If the address is not in the tables, then
Forward the packet onto every port except for
the port that the packet was received on,
just to make sure the destination gets the
Add an entry in your internal tables linking
the Source Address of the packet to whatever
port the packet was received from.
Take, for example, a simple network consisting of a four-port transparent bridge with five stations attached to it. The ports on the bridge shall be numbered one through four, with Station A and Station B on port 1, no station on port 2, Station C on port 3, and Station D and Station E on port 4 (see Fig. 1). If you have a non-graphical browser, it may help you draw this out on paper. The bridge has just been brought on-line, and its tables are empty.
Station B transmits a packet destined for Station C. Since the bridge doesn’t know what port station B is on yet, it puts the packet out onto every port except Port 1 (the packet came from Port 1, so the bridge knows that the packet has already been seen by stations on Port 1). This behavior is know as flooding. The bridge also examines the Source Address in the packet and determines that Station B is attached to Port 1. It updates its tables to reflect this (see Fig. 2).
Now that the bridge knows where Station B is, it will forward packets destined for Station B only onto Port 1. As stations transmit packets, the bridge will learn the location of more and more stations until, finally, it knows the location of every station that is attached to its ports. The beauty of the system is that even if the bridge doesn’t know the location of a station, packets still get sent to their destination, just with a tiny bit of wasted bandwidth.
Finally, the bridge ages each entry in its internal tables and deletes the entry if, after a period of time known as the aging time, the bridge has not received any traffic from that station. This is just an extra safeguard to keep the bridge’s tables up-to-date.
- Spanning Tree Algorithm: A set of rules for determining bridge paths, called the ‘Spanning Tree’ algorithm, is used to prevent bridge drops in networks. This section discusses the implementation of the Spanning Tree Algorithm.
Spanning Tree: What is it?
As we discussed in the essay on learning bridges, one of the guiding principles in transparent bridge design was that the bridges be as automatic as possible.
The Spanning Tree Algorithm is a means by which bridges can eliminate loops in the network topology. A bridging ring occurs when packets can get from an arbitrary point A on the network to an arbitrary point B on the same network through more than one path. For an example of a simple bridging ring, imagine a network with two stations, Station A and Station B, and two bridges, Bridge 1 and Bridge 2. For the sake of clarity, we will also divide the network into two halves, the top half and the bottom half. Station A is connected to the top half of the network and Station B is connected to the bottom half of the network. Both Bridge 1 and Bridge 2 connect the top and bottom halves of the network (See Fig. 1). This is a bridging ring because packets coming from Station A to Station B can pass through either Bridge 1 or Bridge 2.
We could leave it up to the network administrator to make sure that bridging loops never occur, but this solution is hardly desirable. Even if the administrator was willing to invest the time and effort to make sure that such things didn’t happen, human error is working against him. With Spanning Tree, the administrator needn’t worry about whether loops are out there; the bridges take care of it for him.
- Bridge Loops: If a bridge loop occurs in a network the results are often unpredictable but often catastrophic. This section overviews the issues related to bridge loops.
The Requirement For A Spanning Tree
Why do you need Spanning Tree? Why are Bridging Loops so bad? Those are essentially the same question. To answer the question, let’s take a look at what happens when a bridging loop is present in the network. This discussion assumes that you have read the previous pages in this section on Bridge Technology.
For the sake of this discussion, let us consider an imaginary network consisting of two stations, Station A and Station B, and two bridges, Bridge 1 and Bridge 2. For the sake of simplicity, the bridges have only two ports each. The network has been divided into two halves, the top half and the bottom half, and each bridge has one port attached to each half of the network (see Fig. 1).
As described in the essay on Learning Bridges, when the bridges are first brought up, their tables are empty. Let us observe what happens when Station A sends a packet to Station B. The packet goes onto the wire, and the bridges, both of which are listening in promiscuous mode, capture the frame (Fig. 2).
Both bridges make an entry for Station A in their internal tables, which now look like this:
|Bridge 1||Bridge 2|
|Station ID||Port to Use||Station ID||Port To Use|
|Station A||Top Port||Station A||Top Port|
Then, since the bridges don’t know yet where Station B is, they will flood the packet onto every port except the port that the packet came from. In our simple two-port example, the only port that the bridges need to flood onto is the bottom one. Both bridges will queue the packet to be transmitted onto the bottom port and, through the media access method (i.e. either Ethernet’s CSMA/CD or Token Ring’s token passing), one of the bridges will get to talk onto the bottom segment first. Let’s say that bridge is Bridge 1. Bridge 1 transmits the packet onto the bottom segment (Fig. 3).
Now things start to get interesting. Station B, which is on the bottom segment gets the packet, but so does Bridge 2, which is listening in promiscuous mode. Remember, however, that these are transparent bridges. When Bridge 2 sees the packet, there is no way for it to know that the packet came from Bridge 1 and not Station A. Bridge 2 dutifully updates its tables to reflect the fact that Station A has moved to the bottom segment. How else could a packet from Station A come in on Bridge 2’s bottom port? A bridging loop exists — that’s how, but the bridges don’t know that. Now the tables look like this:
|Bridge 1||Bridge 2|
|Station ID||Port to Use||Station ID||Port To Use|
|Station A||Top Port||Station A||Bottom Port|
As you can see, the bridging ring is already causing trouble. Now, there is a bridge whose internal tables are wrong. It gets worse, however. Bridge 2 has yet to transmit its copy of original packet destined for Station B onto the bottom segment. Eventually, it gets the chance (Fig. 4), and now, Bridge 1 sees a packet coming from Station A on its bottom port and updates its tables. Bridge 1 still doesn’t know where Station B is, so it floods the packet onto the top network.
The tables now look like this:
|Bridge 1||Bridge 2|
|Station ID||Port to Use||Station ID||Port To Use|
|Station A||Bottom Port||Station A||Bottom Port|
Also, Station B is probably a little confused here. It has seen the same packet come from Station A twice. Who knows how it will respond. The process that we have seen here is really just the beginning of a huge cycle. Each bridge will see packets that appear to be coming from Station A (they’re really coming from the other bridge) and flood them onto the other segment. Even worse, new packets will continually be created by the bridges until the network is overwhelmed with this looping traffic.
In fact, it doesn’t matter where on the network Station B is. Nor does it matter how many bridges are involved in the loop, or how many ports the bridges have. The problem outlined here happens in any case where a bridging ring occurs.
So, in a nutshell, bridging loops cause trouble because of the very feature that makes bridges so desirable: their transparency. Because the bridges don’t realize that packets are being forwarded from another bridge, they continually flood the packets onto their ports, creating more packets, which are flooded, creating more packets, etc…