CartStorm control is a very useful feature on Catalyst switches. It allows us to control how much unicast, multicast or broadcast traffic is received on a certain port and if this rate becomes “unacceptable”, act on it. By act, I mean that we can either block the offending traffic or completely disable the port. Pretty useful to prevent broadcast storms, runaway multicast source, or a naughty workstation that has no business transmitting that much unicast.
However, there are certain aspects of storm control that are not widely known and some that, for this or other reason, are completely wrongly understood in CCIE community. I will mention the less understood bit first and then get to the business of dispelling with one myth.
Storm control in its functionality is very similar to traffic policing. However, unlike traffic policing that can police traffic based on several criteria, like IP address, MAC address, source or destination ports, etc., storm control can act only based on traffic type. This, we all know.
What is less widely known is that storm control, unlike traffic policing, has a fixed interval during which it performs its limiting function. This interval is exactly one second. When configured not to completely disable the port, storm control will measure and completely block the inbound traffic on these fixed intervals, if it exceeds the specified threshold. For further reading, take a look at the Catalyst 3560 configuration guide, section titled Understanding Storm Control.
The Myth
The widely accepted truth is that, when it comes to storm control “broadcast traffic is a subset of multicast traffic”… or was it the other way round? It doesn’t really matter, the reason here lies in the format of the MAC addresses. We all know that broadcast MAC address is “all ones”, or FFFF.FFFF.FFFF in hex. We also know that all multicast MAC addresses begin with 0100.5E. And here’s the catch. See that “1″ – that one comes from so-called I/G bit in the address, which is used to signify number of recipients. If it’s 0, then it’s one host. If it’s one, then it’s “a group”. Now, if we look at the broadcast address above – it also has “1″ in this field – of course it does, it has 1 in every bit. The myth then goes on to tell us that because of this fact, switches are “unable to differentiate between broadcast and multicast” traffic.
Dispelling the Myth
Let’s configure a simple testbed consisting of one router and one switch. I will use R1 and Cat2 in one of the ProctorLabs racks. Let’s create a very basic configuration on R1 and Cat2.
R1(config)#interface FastEthernet0/1 R1(config-if)#ip address 10.0.0.1 255.255.255.0 R1(config-if)#no cdp enable R1(config-if)#no shutdown
Cat2(config)#interface FastEthernet0/1 Cat2(config-if)#switchport access vlan 1 Cat2(config-if)#switchport mode access Cat2(config-if)#switchport nonegotiate Cat2(config-if)#spanning-tree portfast Cat2(config-if)#spanning-tree bpdufilter enable Cat2(config-if)#no cdp enable
The reason for disabling CDP is that I don’t want any multicast traffic on the port whatsoever. Now, let’s see if storm control is configured.
Cat2#show storm-control FastEthernet0/1 unicast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Cat2#show storm-control FastEthernet0/1 multicast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Cat2#show storm-control FastEthernet0/1 broadcast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ----------
Of course it isn’t. Next, let’s configure very low-threshold storm control for broadcast traffic and generate some of it from R1 and see what happens.
Cat2(config)#interface FastEthernet0/1 Cat2(config-if)#storm-control action trap Cat2(config-if)#storm-control broadcast level 0.01
R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
Cat2#show storm-control FastEthernet0/1 broadcast
Interface Filter State Upper Lower Current
--------- ------------- ----------- ----------- ----------
Fa0/1 Blocking 0.01% 0.01% 17.84%
We can clearly see that storm control is blocking our broadcasts. That’s what we expected. But, what happens if we generate a lot of multicast traffic? Let’s try, but before we do that, we need to configure few more things on R1.
R1(config)#ip multicast-routing R1(config)#interface FastEthernet0/1 R1(config-if)#ip pim dense-mode
Cat2(config)#interface FastEthernet0/1 Cat2(config-if)#storm-control multicast level 0.01
Now, let’s verify that storm control is configured, but not actually blocking anything.
Cat2#show storm-control broadcast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Fa0/1 Forwarding 0.01% 0.01% 0.00% Cat2#show storm-control multicast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Fa0/1 Forwarding 0.01% 0.01% 0.00%
Very good. Now, let’s generate some multicast traffic and see what happens to our storm control!
R1#ping 239.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 239.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
Cat2#show storm-control multicast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Fa0/1 Blocking 0.01% 0.01% 11.08% Cat2#show storm-control broadcast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Fa0/1 Forwarding 0.01% 0.01% 0.00%
Clearly, multicast is being blocked, but not the broadcast! What happens now if we generate a lot of broadcast?
R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
Cat2#show storm-control broadcast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Fa0/1 Blocking 0.01% 0.01% 16.98% Cat2#show storm-control multicast Interface Filter State Upper Lower Current --------- ------------- ----------- ----------- ---------- Fa0/1 Forwarding 0.01% 0.01% 0.00%
Are We Testing Properly?
What we know at this point is that switch tells us that it’s not blocking multicast when we send broadcast storm and vice versa. What we don’t know is if the traffic is actually reaching anywhere… and how much of it. Luckily, we have more routers to help us here. Let’s introduce R2 to our topology and use the interface on the same switch. Brief config to get things rolling.
Cat2(config)#interface FastEthernet0/2
Cat2(config-if)#switchport access vlan 1
Cat2(config-if)#switchport mode access
Cat2(config-if)#switchport nonegotiate
Cat2(config-if)#spanning-tree bpdufilter enable
Cat2(config-if)#spanning-tree portfast
Cat2(config-if)#no cdp enable
Cat2(config-if)#no keepalive
R2(config)#interface GigabitEthernet0/1 R2(config-if)#ip address 10.0.0.2 255.255.255.0 R2(config-if)#load-interval 30 R2(config-if)#no cdp enable R2(config-if)#no keepalive R2(config-if)#no shutdown R2(config-if)#^C R2#ping 10.0.0.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms R2#clear counters
Note that I used “no keepalive” command. This is because I don’t want interface counters to show any traffic except the one we are going to generate. We will also have interface counters show 30 second statistics. We have connectivity with R1, so let’s test. First, we ping broadcast and see what happens. Note, we need to ensure that ping lasts for than one second! 2500 packets should be enough.
R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:11, output 00:00:11, output hang never
Last clearing of "show interface" counters 00:00:21
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 212000 bits/sec, 16 packets/sec
30 second output rate 212000 bits/sec, 16 packets/sec
754 packets input, 1141556 bytes, 0 no buffer
Received 754 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2 multicast, 0 pause input
0 input packets with dribble condition detected
754 packets output, 1141556 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
R2#clear counters
We can obviously see that the traffic was blocked. What we don’t know is which storm control statement did it. Multicast or broadcast. Let’s remove multicast one and try again.
Cat2(config)#interface FastEthernet0/1 Cat2(config-if)#no storm-control multicast level 0.01
R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:09, output hang never
Last clearing of "show interface" counters 00:02:11
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 231000 bits/sec, 19 packets/sec
30 second output rate 231000 bits/sec, 19 packets/sec
687 packets input, 1040118 bytes, 0 no buffer
Received 687 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 6 multicast, 0 pause input
0 input packets with dribble condition detected
687 packets output, 1040118 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
R2#clear counters
Very similar result. Another test, let’s return multicast storm control, remove broadcast one and re-test broadcast ping.
Cat2(config)#interface FastEthernet0/1 Cat2(config-if)#no storm-control broadcast level 0.01 Cat2(config-if)#storm-control multicast level 0.01
R1#ping 10.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:15, output 00:00:15, output hang never
Last clearing of "show interface" counters 00:01:55
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 657000 bits/sec, 54 packets/sec
30 second output rate 657000 bits/sec, 54 packets/sec
2500 packets input, 3785000 bytes, 0 no buffer
Received 2500 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 5 multicast, 0 pause input
0 input packets with dribble condition detected
2500 packets output, 3785000 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
R2#clear counters
OK, how about multicast ping? Let’s try right away and see what happens. Remember, now we have multicast storm control configured. Before we do that, we need to ensure that multicast traffic is flooded by our switch.
Cat2(config)#no ip igmp snooping
R1#ping 239.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:12:45, output 00:10:12, output hang never
Last clearing of "show interface" counters 00:00:16
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 406 multicast, 0 pause input
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
R2#clear counters
We can see that storm control works, as expected. Let’s apply broadcast storm control and remove multicast one, before we end this test.
Cat2(config)#interface FastEthernet0/1 Cat2(config-if)#no storm-control multicast level 0.01 Cat2(config-if)#storm-control broadcast level 0.0
R1#ping 239.0.0.255 size 15000 repeat 2500 timeout 0 Type escape sequence to abort. Sending 2500, 15000-byte ICMP Echos to 10.0.0.255, timeout is 0 seconds: ...................................................................... [... a lot of pings ...]
R2#show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0011.9369.1481 (bia 0011.9369.1481)
Internet address is 10.0.0.2/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 100Mb/s, media type is RJ45
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:15:41, output 00:01:54, output hang never
Last clearing of "show interface" counters 00:00:19
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 2502 multicast, 0 pause input
0 input packets with dribble condition detected
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Counter-Arguments
The test above doesn’t test one specific scenario in which we have the mix of broadcast and multicast traffic coming into the port with the storm-control configured. According to some documentation (Catalyst 6500 configuration guide), this particular scenario can have issues if both multicast and broadcast storm control are configured. However, the same warning is not present in the documentation for Catalyst 3560 switches, leading me to believe that these switches do not suffer from the effect described in that document.
Conclusion
While this would require more thorough testing, from this initial test, all I can say is that myth has been dealt a heavy blow. I don’t see that broadcasts are blocked with multicasts, or the other way round. What do you think – is this myth busted? :-)
I would like to thank my fellow IPexpert instructors, Tyson Scott and Brandon Carroll, who contributed greatly to this research.
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
I would like to have one thing cleared regarding the way the switch reacts to so called “control traffic.” I thought this term is related also to routing protocol update, hello packets etc. So, like “control plane traffic”… But, in the Cisco Doc (the link you posted in your text) thereis a NOTE:
“When the storm control threshold for multicast traffic is reached, all multicast traffic except control traffic, such as bridge protocol data unit (BDPU) and Cisco Discovery Protocol (CDP) frames, are blocked. However, the switch does not differentiate between routing updates, such as OSPF, and regular multicast data traffic, so both types of traffic are blocked.”
Marko, can you explain exactly what is the “control traffic”? What exactly falls into this category?
thanks for the great article
Hi Marko,
Can you please share what will be the necessary steps in order to find that info?
I mean say you want to implement STORM CONTROL inside your company catalyst environment. So how you will proceed to gather required info in order to implement this.
can you please suggest tools and steps etc as I am curious to give it a try in my production network but without causing and downtime :)
Hi Marko,
What will be considered as good threshold settings for configuring Storm control in switch environment?
Say I want to configure this feature inside my catalyst environment in order to protect network from any possible Broadcast storm created by some slammer worm or something.
Also what will be the recommended scenarios and threshold levels for configuring unicast/multicast based storm control?
As always – it depends. Configuring any kind of QoS (and storm control is a rudimentary QoS tool) rquires careful planning and implementation. You would need to establish a baseline – what constitutes “normal traffic” in your network and what are normal oscillations from this value. Armed with that information, you may proceed to plan the implementation.
Since all networks are different, there is really no “magic” value.
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
That is awesome. I had bought the myth, but this seems to be a good test.
I’m glad you guys liked it. We have many more new posts coming up soon.
And yes… more mythbusters ;-)
–
Marko Milivojevic – CCIE #18427
Senior Technical Instructor – IPexpert
Join our Online Study List
Great!!!
Thanks Marko for the excellent post.