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