[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Excessive collisions cripple network -- Suggestions for solutions?

Julius Szelagiewicz wrote:
On Wed, 30 Apr 2008, Tom Wolfe wrote:

Our Linux labs continue to work great. However, our network has now become
much bigger, with lots of little satellite switches in our mini labs
(classes that are serviced by a single Cat 5e wire now have 5-15 K12LTSP
clients via simple switches).

Every couple of months it seems that accidentally ?someone? plugs both
ends of an ethernet cable into the same switch. This ends up sending out
collisions like nuts and slows or cripples our network. I then have to
figure out where the problem is and fix it.

Are there any recommendations out there on how to prevent these problems
from affecting my whole network, e.g. is there a switch that will shut
down a port if it's generating too many collisions or problems? And maybe
even email me to alert me of the problem??

Suggestions would be appreciated!

Many optipons, all good options cost money. The simplest if not least
expensive is to use switches that support spanning tree protocol, end
enable it. There is a small packet delay penalty, but it is usually
negligible. All my HP Procurve switches have STP set and have no problem
with looped cabling. since this happens in rooms served by a single cat5
wire, local STP is really crucial. If only a big upstream switch has this
capability, it will stop all traffic from the affected room.

Julius is right.  What you're seeing probably isn't massive collisions, but rather a broadcast storm, which can happen even when everything's Full Duplex (i. e., no collisions).  Several models of switch support STP:

HP ProCurve
Cisco Catalyst (all models)
Amer.com (all managed-switch models)

I've also used some Nortel BayStack 350-24T and 450-24T switches, which do this job very nicely as well.  They make great LTSP switches, and they're relatively inexpensive on eBay.  Look for one with a Gig-E uplink in it.

To get rid of the delay that Julius mentioned, which can take 30 seconds, you should configure all your access ports for "Rapid Spanning Tree", or in Cisco parlance, "port-fast" spanning tree.  That'll reduce that delay from 30 seconds down to 2 seconds.  Leave your uplinks on "normal" spanning tree.

Additionally, you might want to configure your access ports to do rate-limiting for broadcast frames.  This is relatively easy on any managed switch of decent quality.  We do this at my place of work with rather good results.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]