Network Broadcast

[armadillo]

I had a hell of a week last week; all network switches were going mad and lights flashing very fast and freezing up- I looked for a faulty device or network card but I had no success, I suspect it was a broadcasting problem or a loop somewhere on the network. The problem didn't go on for the whole day and it only happened during some hours (started at around 8:40 Am, stopped at lunch time and it started again after lunch and finally stopped at around 3 PM). I had the teachers to bring their laptops to me and we checked all of them but we didn't find faulty network card or wireless. The network seems to behave itself now and god knows when this is going to happen again.

 

Thanks in advance for any advice and help you might offer.

[Geoff]

Enable STP on your core switches.

[kingswood]

STP is the way to go- but make sure there are no hubs around somewhere- makes for a headache

 

http://cisco-engineer.com/new/index.php?option=com_content&task=view&id=27&Itemid=1

 

Paul

[localzuk]

Do you have managed switches? If yes, what type? If no, I would propose them as something for purchase ASAP.

[armadillo]

Thanks guys for your replies. We have two core HP switches a gigabit HP switches, a few DLinks and two 3Coms.

[andyb13]

Our students occasionally loop a network cable from one wall plate to another, affecting the same switch. spanning-tree does not seem to be able to control these problems

[davepettymcp]

I had the same problem students looping cable on two network points, took me while to catch them

[richard.thomas]

Any chance you're running some sort of classroom management software that allows you to see what each student is doing? Something like vision perhaps? I've noticed vision sends out alot of broadcast packets... Could be something to look into...

[Butuz]

Sudden broadcast storms tend to be a network loop caused by a little cherub plugging in a patch cable to two drops. As has been said above, if you have managed switches then spanning stree can prevent this from taking your network down.

 

Good way to find your network loop would be to unplug each of your switches one at a time from your core switch until your core switch returns back to normal activity - at least then you've isolated the loop back to a partiuclar network cabinet / building, you can then further isolate the fault on that particular cabinet until you find the port that's actually looped.

 

Andrew

[m25man]

Guy's,

In STP, ports can be set for blocking, disabled, forwarding, learning and listening.

 

STP & RSTP add an identifing Algorithm to the packet to ensure that it does not cross the same port twice. If the same packet appears on an STP controlled link twice it will be forwarded or discarded depending on the status of any other links.

Some switches do this automatically others may need specific programming to tell the port when to fwd and when to block.

 

STP is used to control Broadcast traffic but within a given context.

 

Scenario,

If you have 5 cabs and they all link together in a loop to provide link redundancy then STP is essential.

If you had 2 switches in a Cab servicing a single classroom and the little toads put a patch across the wall outlets and it bridged the switches, STP will help you.

If you have 8 GB links connected between two switches in a LAG configuration then STP is useful when a link becomes flakey or the LAG configuration is lost (like when you reset the switch without saving the config first!).

 

The best one I ever had was two sites linked by a Gigabit Laser Bridge with a 108mbs Wireless Backup. STP keeps the Wifi link down until the sun shone directly into the Laser Reciever at 3.30 on an autum afternoon the switch realises that the GB link is down and unblocks the wifi link for the duration of the Sun Block once GB link is restored the STP reverts back to the faster link as priority has been configured to do so through the use of a "Cost" value.

 

But when shorting 2 ports at random on the same switch, STP is unlikely to help. This just floods the switch, then all of the attached nodes join in and start to broadcast.

 

Adding STP to a topology that does not actually contain any physical loops will simply add to the overall traffic and latency of the system.

 

What I'm saying is, that STP may if not correctly implemented may make it even harder for you to identify the true cause of your problem.

 

On all but the most expensive equipment the CPU simply wouldn't be able to cope with the demands for traffic control, on cheap switches they would probably struggle to deliver decent STP performance on a single port yet alone 48 at once!

 

In TCP/IP networks broadcast packet is generated when there is nothing else to resolve the ARP request, if DNS or WINS are too busy or are being drowned out by other chatter, clients will begin to broadcast.

At a lower level if the destination mac is unknown to a switch it will ask it's neighbours through a broadcast.

Having lots of different switch makes on you LAN will undoubtebly result in higher broadcast levels as the switches will not be able to exchange switch table information as easily as if they were all from the same manufacturer and shared bespoke discovery protocols.

More than 30% Broadcasts on a given segment and you are in trouble.

 

Each broadcast packet is unique, therefore adding an STP header will not stop the broadcast only add to the overhead!

 

What you need to do is identify the reason for the broadcast or agressive ARP (DOS attack) in the first place and stop it!

 

A single virus or worm application that is scripted to connect the victims node to a non existent remote host can just take off (It's unlikely that the writer has coded in any reasonable fail the app on retry options) thus creating a broadcast beacon looking for an IP that either doesn't exist or is blocked by you own firewall. Half a dozen of these on your LAN you can kiss it goodbye until the user gets the hump and turns the node off! Broadcast stops network returns to normal without explaination.

 

A misconfigured staff laptop or a students own device could all trigger a broadcast storm as can a loose or broken RJ45 connector.

 

Gratuitous ARP requests due to an improptu IP address change can give switches a headache, duplicate IP addresses or DNS Cache pollution on your own DNS server can all be the catalyst for your nightmare day!

 

If you want to know more here is one of many on the subject of STP

http://www.wwp.com/technology/network-resiliency.asp