Content

| 3.1 |  | Spanning-Tree Protocol Operation |
| 3.1.3 |  | Bridge-table corruption |

A less understood problem than broadcast storms is unicast frames causing network bottlenecks. Figure describes how a unicast packet can cause such a problem. Host A possesses a prior ARP entry for Host B and wants to ping 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. Consider the scenario relative to Cat-1 alone. Cat-1 does not have an entry for the MAC address of Host B, BB-BB-BB-BB-BB-BB, in its bridging table; as a result, it floods the frame to all other ports. Cat-2 then receives the frame on Port 1/2.

Two things happen at this point:

- First, Cat-2 floods the frame because MAC address BB-BB-BB-BB-BB-BB is not in its bridging table.
- Second, Cat-2 notices that it received a frame on Port 1/2 with a source MAC address of AA-AA-AA-AA-AA-AA (from Host A).

As a result, it changes its bridging table entry for the MAC address of Host A to the wrong port.

As frames loop in the reverse direction (the feedback loop goes both ways), The MAC address of Host A flip-flops between Port 1/1 and Port 1/2 on the switches. 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 switch CPU utilization to 100 percent. From this example, it can be seen that broadcasts are not the only types of frames that can bring down a network.