In some cases, a single layer 2 switching device configured improperly can cause serious connectivity problems, especially on a large network. Problems of this nature behave similar to Denial of Service (DoS) attacks but are slightly easier to track.

Most intranets serve a central location where other internal networks are connected. Whether it is a remote off-site location or only accessible by taking an underground railway, it's usually the best place to start disconnecting backbones to find out which physical subnet is causing the problem. Broadcast storms are generally identified by the simultaneous blinking of LEDs spanning multiple switches. By disconnecting its uplink (or backbone), process of elimination can be used to determine if it is a node connected or another switching device.

In a typical setup, once a subnet is determined to have caused the problem, trimming down the network hierarchy to the very node causing the problem requires hardly more than taking a little walk and disconnecting backbones to track down the building housing the IDF with suspicious activity.

In a recent hunt for the offensive node, we found that a home/office size 8-port Linksys was plugged into itself. Unfortunately, switching devices are apparently incapable of interpreting or ignoring packets that loop back into itself (or the same layer 2 device). Unfortunate indeed...

While we were learning in our Cisco lab in college, we created a small LAN storm. It was interesting to learn that we had two sides of our class, and the second side would steal a lot of our bandwidth. We had a server PC on the other side that added an extra router in hopes to take the extra steps needed to get online. Well I believe he took a line to an outside WAN line, and instead of getting the extra bandwidth to our side of the room, he disrupted the left side of the room and each line went inactive. Sorry if my story is a little rough around the edges, it has been a while since I have been back in class!

I just knew that storms were an interesting, but small threat to our learning process... But we went back and started fresh... and we made sure that we had more openings to the outside world.

LAN Broadcast control
Tracing Broadcast Storms

We have several hundred nodes (1000+) in our LAN. No VLAN's implemented yet. We have to manage some how without it. Often we recieve directed broadcast or broadcsat storm which chokes whole network, most of the times the Core Switch & routers stopped responding. We do use sniffers, iRIS, netflow, solarwinds for analyzing that particular incident by Top 10 Users or finding top traffic generator machine. We use the broadcast storm control command in Cisco switches but ginving right packet per second size is difficult as some time single machine either having virus or make session to outside world machine with limited packet size that is legitimate as given in storm control command but due to excess of traffic works enough to choke the link. Need any quick fix to the problem.