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 loop 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 loop 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...

WildPackets is now Savvius

For the latest information on our products and services please go to our new site at

We in the process of migrating some of our legacy content to our new site, so is still available. If the content you are looking for has already been migrated we will automatically redirect you.