anning Tree Input queue: 0/75/0/0 (size/max/drops/flushes): Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 56185000 bits/sec, 71160 packets/sec 5 minute output rate 56277000 bits/sec, 70608 packets/sec 48383882 packets input, 112738864 bytes, 0 no buffer Received 48311185 broadcasts (o multicast) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 36608855 multicast, 0 pause input 0 input packets with dribble condition detected 45107032 packets output, 4212355164 bytes, 356 underruns 0 output errors, 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. 99.9 percent of the traffic we're seeing now 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 is 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 fo/14 3550-I0S(config-if)# no switchport 3550-IOS# sho proc cpu hist 666669999999999999999999999999999999999999999999 11111111119999999999999999999999999999999999999999999 CPU% per second (last 60 seconds) Broadcast Storms This example showed 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