Broadcast Storms and Fault-finder broadcast-storm sensitivity

[joe_butler]

Hi everyone,

I am fairly new to procurves and would like to know more about possible methods of eliminating broadcast storms.


I am currently forcing all user ports onto MDIX-MODE MDIX to stop people looping the switch either on the face or via two wall ports. It sounds silly but this has helped to reduce storms with our users.

I have also experimented with broadcast limits to help reduce the impact of a loop and give me more time to troubleshoot remotely. I have not been overly impressed with the results for two reasons.

1. The broadcast limit seems to 'refresh' meaning that every second or two it will cap it to the specified limit.
2. The loop still seems to cripple the system and instead of broadcast flooding the ports an unusaul ammount of unicast traffic leaks out.

Finally I have the procurve manager set to send me alerts when there are excessive broadcasts. These appear to be incredibally sensitive and get annoyed by printers, faxes, large quantities of DHCP requests etc.

I have experimented with:

fault-finder broadcast-storm sensitivity low

and by removing this line from the code. If someone knows the actuall thresholds for the fault-finder I would be interested to know.






ANYWAY AFTER THAT MARATHON! if your still reading then what im really after is ideas or suggestions from people who have managed to combat looping on procurve networks.

Thanks for reading,
Joe

[Matt Hobbs · Accepted solution]

Hi Joe,

The two most effective features which will help prevent loops which cause your broadcast storms are spanning-tree, and loop-protect.

With these two features enabled, loops should be a thing of the past.

[joe_butler]

Thanks Matt,

I can't believe I hadn't noticed the loop-protect option. Im racking a 5406 as we speak and id love to include it on there however on my return to the office I will dig out some nasty little auto-crossing netgear switches and do a full test into the protection this can offer!

Thanks again,

Joe

[Matt Hobbs]

The best thing about loop-protect is that it uses a standard multicast address which all switches will forward. Spanning-tree on the other hand uses a range (01:80:C2:00:00:00) that is not meant to be forwarded on 802.1D compliant switches.

http://standards.ieee.org/regauth/groupmac/tutorial.html

"IEEE 802.1D MAC Bridge Filtered MAC Group Addresses: 01-80-C2-00-00-00 to 01-80-C2-00-00-0F; MAC frames that have a destination MAC address within this range are not relayed by MAC bridges conforming to IEEE 802.1D."

The problem is that there are many switches out there that do not support spanning-tree, yet still filter these MAC addresses - this prevents a loop from ever being blocked by spanning-tree if such a device is involved in the loop.

[joe_butler]

Sounds good,

I had absolutely no intention of using spanning tree it invariably causes issues no matter who the vendor.

I'm on an avaya course this week. Since the ethernet phone ports they use are auto crossing with no way to force the port setting to MDI or MDIX Loop-protect looks like the only option to finally remove the remaining oportunities for our users to loop. I am assuming loop-protect drops 1 or both of the offending ports?

As said earlier this will get a full lab on my return from training.

Thanks for you help,

Cheers,
Joe