A broadcast storm occurs when packets are continuously forwarded around a network, grinding it to a halt. This is most easily illustrated with a simple example. Consider the network in Figure 3-1, with two bridges (Bridge A and Bridge B) connecting network segments 1 and 2. At first glance, the network probably looks good – if one of the two bridges fails, a second redundant path to the other segment exists. However, this design quickly becomes problematic, as I describe in the steps below.
Figure: Bridged network with redundancy.
Imagine that Computer 1 wants to send a frame to Computer 2. Let’s say that the bridges have already discovered that Computer 1 is on segment one, and that Computer 2 is on segment 2, and they have already added both to their MAC address tables. This is outlined in the figure below.
|
Bridge A MAC Table |
|
Bridge B MAC Table |
||
|
MAC |
Interface |
|
MAC |
Interface |
|
Computer 1 |
1 |
|
Computer 1 |
1 |
|
Computer 2 |
2 |
|
Computer 2 |
2 |
Remember that both segments are shared. As such, when Computer 1 sends a frame, both Bridge A and Bridge B will see it. Herein lies the first problem – both bridges see the frame and both will forward it. This means that 2 frames will be forwarded onto segment 2, even though only one was originally sent.
When those frames are forwarded, we have an even bigger problem. The frames will not only arrive at Computer 2 twice, but will also end up being encountered by both bridges on their segment 2 interfaces, as shown in the figure below.
Figure: Frame forwarded by both Bridge A and Bridge B.
So why is this a problem? Well, you’ll need to recall how a bridge builds its forwarding table. In this case, Bridge A will see the frame forwarded by Bridge B, and will look at the source address. The source address is still that of Computer 1. Because of this, Bridge A will now think that Computer 1 has been moved to segment 2, and will change its MAC address table. In the same way, Bridge B will see the frame forwarded by Bridge A, and will do the same. See the problem starting already?
Now let’s say that Computer 2 responds. The bridges will not forward these frames, because they think that Computer 1 is also on segment 2. Since Computer 1 never gets a response, it sends the original frame again – a bigger problem. The bridges now believe that Computer 1 is again on segment 1 (by looking at the source MAC address), and change their MAC tables yet again. 2 frames again get forwarded, and so on. Ultimately this corrupts the MAC address table. Based on the quantity of traffic being moved (remember, it could be many systems transmitting), a broadcast storm takes over the network. All this happens simply because we wanted a little redundancy.
So how do you avoid this scenario? Am I saying that you can’t have redundant links between switches? Not at all, but you will need a little help. In order to avoid the loops just described, you’ll need to use something called Spanning Tree Protocol (STP), defined in standard 802.1d. It will eliminate network loops until an active link loses connectivity. When this happens, Spanning Tree will automatically reconfigure the network to use the redundant path.
