storm-control guidelines and best practices

gnijs · ‎08-10-2009

Hi all,

Are there any "best practises" regarding the value of storm-control ?

I want to limit inbound broadcasts to 100 packets/second on each port on our Access VLANs. This seams a reasonable number.

1) 70% as i see in some documentation, i find way too large to be of any value.

1) i don't want to rely on percentage because of the difference of Fa and Gi. 10% of a gigabit is already 100 Mbps of broadcast traffic which is way too large.

2) Each Access port carries voice and data vlans. Each vlan is /24 size. Storm-control is an aggregate of all broadcast received on all vlans on an access port. Still two devices should not generate more than 100 pkts/sec broadcasts, i feel.

Lucien Avramov · ‎08-10-2009

The hard part about establishing guidelines like this is that what works beautifully for one person and their network would be a really bad decision under someone else's circumstances.

A long time ago, some perceived rules of broadcast levels shouldn't top 20 percent of a network's traffic were set. This is definitely a good rule to go with, but if you simply put storm control on your switches as a way to "fix" things, you may end up with more issues than you planned.

Certain OS do a significant broadcasting (whether all 255s or a subnet-level broadcast doesn't matter). These broadcasts are how a good amount of internetworking and discovery operations actually take place.

There are settings within the operating system that we can do to change the behavior and yet control the operations. If we simply killed the broadcasts, we may end up with intermittent reachability of machines and/or services within the OS guidelines. That would irritate just a few people.

With multicast traffic, if you don't have any running, no matter what level you pick, you may never see an issue one way or the other. For unicast traffic, you should probably have a good reason to implement filters like this, and I'd suggest different policing techniques depending on what you were attempting to accomplish.

The bottom line is that we can come up with numbers all the time that may appear to be "good" or "best practices" but unless your network is a cookie cutter that lines up with everyone else's standards, then it may not help you.

The best thing you can do is to understand what is happening on your network: on each VLAN, at Layer 2 and at Layer 3. Then understand what you want to happen on your network. Then design your network accordingly. Let the business needs drive your networking, and you are guaranteed to make more people happier more often.

You may use tools such as a sniffer (network analyzer like Ethereal or Wireshark, Network General or others), a separate network analysis device (like Fluke's EtherScope systems) or something built in to many routers like NBAR protocol discovery.