The Problem of Loops

This material is written with an assumption that the reader has a fairly significant knowledge as to what 'Ethernet Bridges' are and some basic networking terminology. For an introduction to the basic problem, Please go through "Introduction".


Consider the simple network topology that is given above. Let’s say that Computer A sends a frame out onto to network. Because all devices on Network A are part of the same segment, it will be seen by all hosts, including interface A on Bridges 1 and 2. The bridges will use the source MAC address information to add entries to their forwarding tables, which will identify Computer A as being accessible via their network A interfaces. So far, so good. By the same token, let’s assume that Computer B also sends out a frame. Bridges 1 and 2 will also see this frame, and will add Computer B to their respective forwarding tables, as being accessible via interface B Hence at this point, the forwarding table for the bridges would look like as shown below:
Host AddressPort
0000.0000.000AA
0000.0000.000BB
At this point, life is still pretty good on our network, since both bridges are aware of the correct location of both hosts. The problem arises when Computer B attempts to communicate with Computer A, or vice versa. For example, let’s say that Computer B wants to communicate with Computer A. It sends out a frame, with a source address of 0000.0000.0000B, and a destination address of 0000.0000.000A (note that these addresses are hypothetical, for illustration purposes). Even though only one frame is sent by Computer B, it will be “seen” by both bridges, since they are all part of the same domain. This is illustrated below.

Upon receiving the frame, Bridge 1 will inspect the destination MAC address and notice that the host with address 0000.0000.000A is accessible via its network A interface. As such, it will forward the frame. Unfortunately, Bridge 2 will do the exact same thing – and forward a second copy. All things considered, nothing seems too bad so far. You might think that the worst of this is that Computer A would ultimately receive two copies of the same frame, and just be a little confused. Unfortunately, the problem is larger still. This is because those frames that were forwarded onto segment A will not only be encountered by Computer A, but also the “A” interface of each of the bridges. This is illustrated below.

This is where the fun begins. In encountering the frame forwarded on to segment A by Bridge 1, Bridge 2 will take a look at the source MAC address of the frame and will notice that it came from Computer B (the source address). Since the frame was received on it’s “A” interface, Bridge 2 will automatically assume that Computer B has moved, and it now part of network A (recall that bridges and switches build their forwarding tables by looking at the source address of a frame). As such, it will change its forwarding table to reflect the change. The exact same process would occur on Bridge 1, according to the frame forwarded by Bridge 2. Now, both Bridge 1 and Bridge 2 assume that A and B are on the same segment. When Computer A attempts to respond to Computer B, neither bridge will forward the frame – as far as they’re concerned, both hosts are on the same segment. If that wasn’t bad enough, the problem gets worse. Since it doesn’t receive a response, Computer B will likely try again, sending out another frame. Upon seeing this frame on their “B” interfaces, both bridges will again think that Computer B has moved, back to segment B. They will thus update their forwarding tables, and again each forward a copy of the frame on to segment A. Starting to see the problem? If it doesn’t seem like a big issue with only 2 clients, imagine a network with 50 clients on each segment, and this situation occurring over and over again. This, ladies and gentlemen, is a broadcast storm. In even the smallest bridged or switched environments, a loop can easily and quickly bring a network to its knees. This problem is referred to as "Broadcast Storms". An obvious question that would pop up at this point is 'Why then can't we do off with Loops?". Sadly, the answer is No. Loops offer great redundancy to a network in that should a particular link fail, there would be an alternate path available for nodes to communicate. Another less likely scenario is that loops might also be introduced by accidents... The Spanning Tree Protocol addresses the problem of loops and Broadcasting storms wonderfully. Go over it in the next section.