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

["Terrell Prudé Jr."]

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
>   

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)
Raptor
Avaya

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.

--TP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/k12osn/attachments/20080501/b4a13e77/attachment.htm>