Cisco – switchport block multicast vs storm-control multicast

ciscomulticastswitch

I'm not sure what is the difference in behaviour between switchport block multicast and storm-control multicast and I don't think cisco elaborates the difference very well in their documentation, other than the fact storm-control grants you levels of control, but for this case, suppose the storm-control only lets you pick up 0 or 100. How is it any different from switchport block, for instance?

Update: I accidentally wrote "switchport block unicast" when I intended to write "switchport block multicast".

Best Answer

Well the first difference would be that switchport block unicast blocks unknown unicast and storm-control multicast blocks multicast packets.

The difference between switchport block XXXcast and storm-control XXXcast is exactly what you want to exclude in your question. You can pick any percent value for storm-control. It will block traffic of the specified type which exceeds this percentage of bandwidth on the port. switchport block is a simple yes/no. It blocks everything when activated.

Update:

As ytti mentioned, on some low-end boxes when storm-control multicast is exceeded all traffic will get filtered. In that case storm-control multicast is dangerous and useless.

Also on high-bandwidth interfaces (1/10GE) please remember that even a small percentage of the bandwidth can kill a box that punts the packets to the CPU. If possible use CoPP to protect the control plane. Also always use pps instead of bps for CoPP if possible.

Related Solutions

Cisco – Is ‘switchport protected’ supposed to block unicast flooding

The information that I'm seeing conflicts -- the wikipedia page on unicast flooding cites protected mode as a mechanism to block flooding, while Cisco's documentation says that switchport protected doesn't matter, and that switchport block unicast would still be needed to prevent flooding.

switchport protected is used to enforce privacy within a vlan... the command prevents ports from talking to other ports configured with switchport protected. This command reduces flooding as a side-effect of using it on all ports in a Vlan, but it does much more than "just" remove flooding from a switchport. Honestly, I think there are better ways to accomplish your goals.

switchport protected is useful if you're aggregating colocation customers in the same vlan; this command is one way to offer privacy between the customers without the complications of private vlans. The wikipedia article you mentioned, says you can "bounce" traffic off the default gateway (which should not be on a protected switchport) to reach those other destinations...

switchport block unicast does stop unknown unicast flooding; however, see below for why I think you shouldn't need this command.

However, I recently ran into an issue where on a 2950G running some relatively ancient 12.1(22) code, unicast flooding seemed to be completely broken for a protected port -- the aging time on the switch was 5 minutes, while the router's ARP timeout was 30 minutes, and the one TCP connection utilizing this interface had a tendency to sit dormant for 10 minutes at a time - and be non-functional when waking up after 10 minutes in this case.

As I mentioned in my comment, if there is any potential for an asymmetric routed path in this network, you either need unknown unicast flooding, or you need to match the CAM and ARP timers to ensure that CAM entries don't age out before the ARP entries.

In most cases, matching the ARP and CAM timers is the right way to fix the situation, but the choice is yours...

EDIT to respond to the comments:

Setting the timers to match is working great as a workaround - I just don't understand why the flooding isn't happening as expected.

Quoting from "CCIE Practical Studies, Volume 2", page 115 by Karl Solie, Leah Lynch, Charles Ragan:

If unknown unicast and multicast traffic is forwarded to a protected port, there could be security issues. To prevent unknown unicast or multicast traffic from being forwarded from one port to another, you can configure a port (protected or nonprotected) to block unknown unicast and multicast traffic.

3550_switch(config-if)#switchport block unicast
3550_switch(config-if)#switchport block multicast

Cisco: storm-control unicast

So does storm-control unicast only measure the pps rate (or bps rate) of frames that are for destinations not in the CAM tables, or all destinations that aren't a broadcast or multicast address (so just the total number of unicast frames)?

I have to confess that I mistakenly trusted the Nexus doc below which said only unknown unicast is rate-limited; however, that's definitely wrong for Cisco IOS. The reality is (at least on IOS platforms) that unicast storm control affects all unicast traffic; the Cisco Nexus doc I quoted said it only affected traffic that was unknown unicast. I will endeavor to test on Nexus at a later date.

In an effort to atone for my mistake, I built a quick screencast of what happens when I:

Configure a Cisco IOS switch with unicast storm-control to throttle at 1Mbps.
Use speedtest_cli.py to start a unicast download from speedtest.net
Reconfigure the switch without unicast storm control
Download from speedtest.net again...

Hit your refresh button to restart the screencast at the beginning

storm-control screencast

Bottom line

Unicast storm-control affects all unicast traffic in Cisco IOS
Unicast storm-control is applied on traffic inbound to the switchport

My Original quote from the Nexus docs, which I applied to the OP's Cisco 2960

~~Quoting the Nexus Storm Control Docs (emphasis mine):~~

~~"You can use the traffic storm control feature to prevent disruptions on Layer 2 ports by a broadcast, multicast, or unknown unicast traffic storm on physical interfaces. "~~

Storm control operates the same way across Cisco platforms; if the destination-mac-address is not in the CAM table, then then the switch must flood it out all ports in the Vlan (except the one it came in on). Suffient quantities of this kind of traffic would trigger your Unicast Storm Control thresholds.