Another part of the IPExpert Security Video-on-Demand, Storm-Control!
Storm-Control can be used to limit, or to set thresholds for different types of traffic (Broadcast, Multicast and Unicast) on a specific interface you choose (or that you´re asked for). ;)
You can set your threshold to whatever the top level that you want, and the traffic will be limit to that. Also, on 3560 Switches you can set falling thresholds too! Basically it is telling the switch how much traffic do I want (or don´t I want) through that interface.
Now... to the tricky part... just suppose you want to limit the broadcast/multicast traffic in a specific interface... how would you set?! Would you allow more Broadcast traffic than Multicast?!
Hmm... good question, let´s step back for a while... What´s a Layer 3 Broadcast?!
A Layer 3 Broadcast can be the "All Hosts" which is the 255.255.255.255, or it can be a "Subnet Brodcast", for example 172.168.10.255 is the broadcast IP of the /24 subnet; just keep in mind that if the actual subnet mask change, the Broadcast IP will also change too!
Now... how about Layer 3 Multicasts?! What those guys are?
Layer 3 Multicasts, known as Class D also, begin with the binary value of 1110 in the first octet. It goes from 224.x.x.x to 239.x.x.x. Also, at Class D we don´t have concept of subnetting of or broadcast reachability! So Broadcasts and Multicasts at "Layer 3" have nothing to do with each other.
Ok! With all that in mind, can you make a decision on how to configure the Storm-Control in one of your switch ports to limit the Broadcast / Multicast traffic?! Not that fast right?! There´s another wonderful world outside "Layer 3" it´s called "Layer 2" ! :)
At Layer 2, Broadcasts are know as "All F´s" FF-FF-FF-FF-FF-FF, this address represents all devices in a Layer 2 network, we all know that since the CCNA days, so, no big deal!
Now... The Layer 2 representation of IP Multicasts all begin with 01-00-5E. And there´s one specific bit in the MAC Address that defines whether or not it´s a Multicast, the I/G bit!
Take a look at the MAC Address format:
So, like our friend Scott Morris likes to say, the least significant bit of the most significant byte is the I/G bit! And looking at our Multicast Address 01-00-5E (in binary 0000 0001-0000 0000-0101 1110) we can see that this I/G bit is set to 1 in EVERY Multicast!
In that case, the I/G bit defines a Multicast when it´s set to 1, but, how about the Broadcasts?! All bits in a Layer 2 Broadcast are set to 1 (including the I/G bit), so, Layer 2 Broadcasts, in fact, ARE a subset of Layer 2 Multicasts.
All Layer 2 Broadcasts are Multicasts.
All Layer 2 Multicasts are not Broadcasts.
With that in mind, when configuring Storm-Control in a switch port, and, if you´re setting limits to both Multicast and Broadcast, you should set Multicast limit HIGHER than the Broadcast limit (at least set they equal, but never set the Multicast level to be less than the Broadcast level, otherwise, either Broadcasts and Multicasts will be limited by the Multicast level, making pointless the Storm-Control configuration for the Broadcast!).
It´s configured on a per-interface basis, here´s the command list:
| (config-if)#storm-control broadcast level (#)[.(#)] (config-if)#storm-control multicast level (#)[.(#)] (config-if)#storm-control unicast level (#)[.(#)] Level is % of line as maximum threshold Level 100 would permit everything Level 0.0 would disable the frame type |
The following example will enable Unicast Storm-Control on a switch port with an 89% rising suppression level and a 67% falling suppression (remember, falling suppression can only be configured in 3560). It´ll also enable Broadcast Storm-Control on a port to a level of 20%. When the Broadcast exceeds the configured level of 20% of the total available bandwidth of the port within the traffic-storm-control interval, the switch drops all broadcast traffic until the end of the traffic-storm-control interval:
| interface gigabitethernet0/1 |
Just remember, Multicast levels (which includes more things) must be higher, or at least equal, to the Broadcast levels when configuring Storm-Control!
You can use the show storm-control command to verify the operation!
Nice! :)
More information available in do following Websites:
http://tcpmag.com/qanda/article.asp?EditorialsID=317
http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_lay207.html
Posts
2 comments:
As Lee Bowman of Scripps Howard News Service wrote in a report on America's would-be storm breakers, the giant storms are "a vital part of Earth's climate controls, part of the oceans' constant exchange of heat from the equator toward the poles."
Bowman found that a group of scientists think it's worth another try. Joe Golden, a scientist at the University of Colorado, told Bowman, "If we have the slightest chance to do something beneficial without harming the environment or causing some unexpected consequences, we owe it to the taxpayers to give it our best shot."
Even a slight change in direction or a diminishing of the wind force could greatly reduce a storm's capacity to destroy. This year, the storms have caused tens of billions of dollars in damage.
The Department of Homeland Security will spend $1.6 million on modeling to come up with three or four proposals.
The scientists may not come up with the magic bullet, but their storm models may significantly improve the forecasters' powers to predict.
That alone will be increasingly important to our crowded shorelines.
Some important remarks:
1) One very important remark everybody seems to miss, is that storm-control only works on INBOUND packets. It does not prevent a port from being overwhelmed with broadcasts from the core or other access switches.
2) Watch out with stormcontrol on trunk ports ! What is a broadcast on a trunk ? in any "allowed-vlan" ? no. any broadcast in any vlan, even non-allowed ? yes !
2b) The storm-control "drop filter" action will block on all VLANS.
Post a Comment