My Cat 2960 has a port configured with broadcast strom-control with a 10% threshold. I connect a PC on that port and make it generate a massive ARP broadcast message on that port to simulate an ARP strom to see how the switch bahaves.
I can observe that the switch is doing well by blocking the ARP traffic when it reaches more than the 10% of bandwidth: other PC connected on the same VLAN see no ARP message when the storm-control is in action. Fine.
But when look at the CPU load of the switch, I can see that the "ARP Input" process is about 70%.
It seems to me that even if the traffic is blocked, the ARP broadcast traffic is still forwared to the switch CPU for a reason that I cannot understand.
I would think that the storm-control would block broadcast traffic for all including the management of the switch.
Is there something to do woth "Dynamic ARP inspection" ? If any, how can I disable the DAI on a Cat 2960 ?
Thanks for your replies.
your PC sending a lot of ARP broadcast frames was in the same vlan as the management IP of the switch ?
If so the ARP requests are examined by the the IP stack of the switch.
If so try to put both Pcs in a different Vlan and repeat the test it should provide better different results.
Hope to help
Yes, the PC sending the ARP broadcast is in the same VLAN because I need that the switch can be reached by the PC if that PC is a Supervision machine.
Just for test, I shutdown the vlan interface and see that the CPU is decreasing but has a high level (decrease form 99% to 40 %).
my understanding is because the ARP Input process runs in sofware, you should expect to see some High CPU Utilizaton. High CPU utilization in the Address Resolution Protocol (ARP) Input process occurs if the switch has to originate an excessive number of ARP requests. The switch uses ARP for all hosts right? not just those on the same vlan but other vlans on the switch, and ARP requests are sent out as broadcasts, which causes more CPU utilization on every host on the switch.
Maybe someone can shed more light on this discussion.
The storm-control feature is to protect the switch and the VLANs that it implement agianst storm traffic coming from equipment connected to it.
So what is the interrest of such a feature if it blocks correctly the traffic to the VLANs but not to the CPU of the switch. If the storm traffic triggers high CPU of the switch then the switch is not operational anymore. So this feature is not useful.
the feature does what its name says : it puts a limit in the volume of broadcast traffic received on port.
In your test conditions you see the effect of process switching of every frame that is allowed: ARP request or gratuitos ARPs have to be processed by the CPU.
If you could at least use a Vlan different from the management vlan the result would be different because there wouldn't be no layer3 stack there and the permitted ARP frames wouldn't be processed but just switched to the other ports in that vlan.
For example if you had a traffic generator you could send broadcast traffic of any type and you could see a different results.
Put the limit to 1% and you should see a lower CPU usage.
It's important to understand that results are greatly affected by test conditions.
If your target is to defend the switch from ARP attacks I agree that storm control is a too generic tool for that.
Hope to help
I do the test in setting the broadcast storm control level to 0% and the CPU is still reaching 99%.
When I shutdown the vlan interface the CPU is around 40%.
I still don't understand why the switch needs to process the ARP message when this traffic is blocked by the storm-control.
It looks like a bug in the IOS.
I have looked at the security advisories for 12.2 (46)SE and i cannot find anything related.
Take in to consideration that your switch model is lower-end switch. Maybe on a higer end switch like 3560/4500/6500, you will get a better result.
after these further details I agree that this behaviuor is not correct it is clearly passing to the CPU frames that should be simply discarded: with a 0% level all should be dropped without hitting the CPU.