Joshua Gitlin wrote:
Apparently (and don't ask me how or why) CUPS on my system had brought the entire campus network to it's knees. (Or so I was told). One of my NICs was sending out broadcast packets as fast as it possibly could, and the second NIC was answering. Both interfaces had their own IP, and somehow all this traffic was disturbing the campus network. To solve the problem, the network administrator had first isolated the network in my building from the rest of the world, and then cut off access to the port in my room. Of course now I had plugged in to my roomate's port and was continuing to broadcast. As the admin was explaining this to me, I unplugged the cable so fast I almost ripped the jack out of the wall!
That's not as surprising as it might sound, in some senses. The phenomenon you're describing is known as a "broadcast storm" and
is fairly well known in the networking world.
The interesting thing is, in general routers are configured to NOT forward broadcast packets, so a broadcast storm will be limited to a given subnet. One would expect a university network to be broken up into subnets separated by routers to *some* degree.. or at least
I would.. so to hear that this brought down the entire
network strikes me as a little odd.
On a related note, I've had similiar experiences caused by
excessive multicast packet traffic. (conceptually not
that much different than broadcast traffic, I suppose).
Our LAN at the office was crawling one day, and when I started watching the wire with TCPDump, I saw all these packets destined
for port 5555.. at the time I had NO idea what it was
all about.. eventually determined that two JBoss
servers that were on the network, were sending / replying
to the IP Multicast requests that JBoss servers use
to discover each other; something to do with their
clustering feature. Those servers didn't need
to be clustered, so I just disabled the Multicast
discovery stuff on each, and BAM, the LAN went back
So yeah, it's not at all unusual for one or two machines on a network, doing something weird, to cause problems for the entire network.
TTYL,
Phil
to normal. -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
