5.1 Basic STP Operations
5.1.3 Bridge-table corruption

Many switch/bridge administrators are aware of the basic problem of broadcast storms; however, few people are aware of the fact that even unicast frames can circulate endlessly in a network that contains loops. The Figure illustrates this point.

In this example, suppose that Host A, possessing a prior ARP entry for Host B, wants to ping (unicast packet) Host B. However, Host B has been temporarily removed from the network, and the corresponding bridge-table entries in the switches have been flushed for Host B. Assume that neither switch is running STP. As with the previous example, the frame travels to Port 1/1 on both switches (Step 2), but this example considers the situation from only the Cat-1 point of view. Because Host B is down, Cat-1 does not have an entry for the Host B's MAC address, CC-CC-CC-CC-CC-CC, in its bridging table.  As a result, it floods the frame (Step 3) to all other ports. In Step 4, Cat-2 receives the frame on Port 1/2. Two things - both bad - will happen at this point:

  • Cat-2 floods the frame because it has never learned MAC address CC-CC-CC-CC-CC-CC (Step 5). This creates a feedback loop and brings down the network.

  • Cat-2 notices that it just received a frame on Port 1/2 with a source MAC of AA-AA-AA-AA-AA-AA. It changes its bridging entry for the Host A MAC address to the wrong port!

As frames loop in the reverse direction (recall that the feedback loop goes both ways), you can actually see the Host A MAC address flipping between Port 1/1 and Port 1/2. In short, not only does this permanently saturate the network with the unicast ping packet, but it also corrupts the bridging tables and drives the switches CPU utilization to 100%. As can be seen, broadcasts are not the only parameters that can bring down a network.