, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 361 output buffer failures, 0 output buffers swapped out Remember that the baseline traffic load for this interface was 1,000 bits per second and 2-3 packets per second. Of the traffic we're seeing now, 99.9 percent is recycled broadcasts. This is a broadcast storm. Rest assured that experiencing one on a live network-particularly one for which you are responsible-is not fun. The storm occurs quickly and affects services immediately. Because this example takes place in a lab environment, I am having fun (though my wife would no doubt have some interesting comments regarding what I consider fun), but all good things must come to an end. Within seconds of disabling one of the trunks, EIGRP stabilizes, and the network problems disappear. I can now telnet to the switch with ease. The CPU returns almost immediately back to normal utilization rates of 0- 1 percent: 3550-I0S(config)#int f0/14 3550-I0S(config-if)# no switchport 3550-IOS# sho proc cpu hist 666669999999999999999999999999999999999999999999 11111111119999999999999999999999999999999999999999999 CPU% per second (last 60 seconds) This example shows how devastating a broadcast storm can be. When the switches involved become unresponsive, diagnosing the storm can become very difficult. If you can't access the switch via the console, SSH, or Telnet, the only way to break the loop is by disconnecting the offending links. If you're lucky, the looped port's activity lights will be flashing more than those of the other ports. In any case, you won't be having a good day. MAC Address Table Instability Another problem caused by a looped environment is MAC address tables (CAM tables in CatOS) being constantly updated. Take the network in Figure 8-3, for example. With Chapter 8: Spanning Tree Switch A CAM table: Switch A MAC: 0030.1904.da60 F0/10 MAC:0030.1904.da60 F0/10 Switch B Switch C Switch B CAM table: Switch CCAM table: MAC: 0030.1904.da60 F0/1 MAC