Does anyone have any experience with/thoughts about the Catalyst 'storm-control unicast' feature? It appears to implement a form of policing with a rather coarse sampling interval (1 sec.) but pretty fine threshold control and range (to one one-hundredth of a percent of "available" bandwidth--much wider and finer than the 'police' command).
I would appreciate any thoughts on whether a policing action with the above attributes would be effective as a rudimentary way to control user ingress bandwidth at the edge. Or would you think the sampling interval would be too coarse?
I lab tested some 3550s a few months back. Below I have included the portion of my report pertaining to "storm control". I have not included the statistical data, only the conclusion.
Ø Another mechanism that can be used to control traffic is storm control. You can configure storm control on an interface and enter the percentage of total available bandwidth that you want to be used by a particular type of traffic. Entering 100 percent allows all traffic (the default), entering 0% blocks all traffic. However, because of hardware limitations and the way in which packets of different sizes are counted, threshold percentages are approximations. Depending on the sizes of the packets making up the incoming traffic, the actual enforced threshold might differ from the configured level by several percentage points. Storm control can be used to control broadcasts, multicasts, or unicasts. Storm control was tested in the lab. The data derived from the tests is attached to this document and is summarized here. The hardware used to generate traffic was a limitation in the fact that at certain packet size / bandwidth settings, CPU usage of 100% was attained before Ethernet bandwidth limitations were met. Also, the ability of the traffic generator to generate sufficient traffic was a limiter. This is seen in the RX Load % column of the attached spreadsheet. The maximum load reported by the switch software was approximately 70% by the interface and 87% by the storm control function. These limitations did not prevent the testing of the storm control function, they only limited the extent of the testing possible. If it is assumed that the traffic generated by the test computer is typical of the maximum that would be seen on the network, the following conclusions can be drawn: a very low setting (20% or less) can be used to control large packets; as packet size decreases the percent of bandwidth used and the storm control values needed to forward traffic increases creating more granularity; a storm control setting that is functional with small packets would have no effect on large packets. It should be noted that small packet traffic greatly increased the load on the segment as compared to large sized traffic so there may some value in controlling the small packets and allowing all large sized packets. For example, if storm control were set to 60%, and the segment was running at 10Mb, 64 byte packets sent continuously would be blocked, thus preventing segment saturation. If the speed of the segment was increased to 100Mb, the percent of bandwidth drop below 60% and traffic would be forwarded. If packet size is increased to 500 bytes or greater, the segment load would decrease sufficiently to allow all traffic to pass forward. It was also noted during testing that the storm control function is implemented one way only. Traffic into the interface from the end user is controlled, but traffic transmitted out the port to the end user is not.
The biggest issue that I saw was the fact that storm control is based on % of bandwidth. As you know, 10% of a 100M = 100% of 10M. I would like to see Cisco rewrite the code in order to set storm control based on actual connected bandwidth. This feature would greatly increase it's value in an auto-sensing environment.
Excellent--thank you for sharing your results. Your last point is well taken. I'm going to be hard-setting the user ports to 10/auto-duplex, so if I use this feature, at least I'll have a "stable" reference point.
"...as packet size decreases the percent of bandwidth used and the storm control values needed to forward traffic increases."
"...if storm control were set to 60%, and the segment was running at 10Mb, 64 byte packets sent continuously would be blocked..."
"If packet size is increased to 500 bytes or greater, the segment load would decrease sufficiently to allow all traffic to pass forward."
Interesting. So just to clarify, do you suppose that this behavior was an artifact of the limitations of the traffic generator (inverse packet size vs. throughput function) or is storm-control more sensitive to segment utilization (rather than throughput) at smaller packet sizes?
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...