Inbound rate policing and its effect on the ASA CPU utilization ?

[shamax_1983]

Hi All,

We have a ASA 5510 and one of the internally hosted services started pushing UDP traffic exceeding 700Mbps from inside interface and killed the ASA ( 100% CPU). I was thinking about applying traffic policing inbound on the inside interface (limiting traffic to only 50 Mbps) and while doing some research on Internet, I found following note on one  of the Cisco's documentation (https://supportforums.cisco.com/docs/DOC-1230)

NOTE 1:

The user has to bear in mind that traffic policed inbound on an interface cannot provide much as the packets have already hit the interface, which means they have already used the available bandwidth. There is an advantage of policing to a value a little less than the available download bandwidth and that is if we start dropping before oversubscribing the link TCP will converge to the optimal throughput value. Though, that  would be practically hard to achieve given that there are multiple flows going through the pipe.

Now I know that that ASA processes incoming packets, doing routing,natting,inspection,ACL matching etc. and It ustilizes the ASA's processing power for all that and in my case definetely the ASA tried all that on incoming UDP and it coudn't handle the load.. that's why It died ( because maximum it can do it 300Mbps).

So my question is, If I do policing inbound on this particular sub interface, as the ASA is dropping packets now, hence not doing further processing like routing, NATing etc, would it help me save the ASA CPU? OR..  becaue, it is now doing the QOS/dropping packets and "thinking" about incoming traffic at a rate of 700Mbps, and doing some processing for polcing, would it still hit the 100% CPU anyway ??  or would it be less processer consuming compared to previously consumed CPU for further processing ??

I understand that I wouldn't be able to save the link bandwidth as this is UDP traffic, and the end host will keep pumping the traffic regardless the dropping at ASA sub interface.. but at lease I will get to save the ASA..

At this point, my only options is to have policing confiured on the ASA, downstream swithces are pretty dumb.. So that's why I'm trying to do this on the ASA level until we upgrade the infrastructure to have a seperate L3 switch tier behind the firewall so it can deal with policing/shaping..

Your comments, suggestions much appreciated...

Thanks

Shamal

[Michael Muenz · Accepted solution]

You could try a service-policy and max connections per client to limit such traffuc storms.

As stated, best way is to limit BW with the switches connected to the server/client.

Michael

Please rate all helpful posts

[shamax_1983]

Thanks ciscomax..

The policing on the sub-interface did save some CPU cycles when it happened again.. But I did not quite get the expected result..  so like you sugggested, I have enabled the max-connections per client feature as an additional restrictive layer.. and also enabled some Threat-detection featuers (with "shun") to restrict the suspisious hosts from eating up the ASA CPU. It looks like working but I still got this fundamental issue that no matter what I do on the ASA, I can't get the UDP traffic to slow down, which intern affects other clients' ability to use the interface to send traffic out (clients who share the same physical interface that is). So I'm going to have to either replace the swithched with something capable of doing policing or probably introduce Nexus 1000v in to the VMware layer and thereby stopping traffic at the VM/host level.. which I belive the best case scenario..

Thanks for your suggestion anyways.. it did help me alot..