Is your ASA having a High CPU issue? Here’s some methods for troubleshooting the issue.
Find out what process is causing the CPU to be high
To see what the current CPU usage is:
- Under normal conditions the CPU should stay below 50% (baseline as per network); if the CPU reaches 100% the firewall will start dropping packets
- FWSM CPU is used for limited traffic processing; during ACL compilation CPU is expected to be near 100% until ACL is compiled
- The show cpu usage command displays the CPU over time as a running average
Now take a look at what the top process is that’s causing it.
Notice what process is taking up the most of the CPU. In this case it’s Dispatch Unit.
This command was first Introduced in Cisco ASA Version 7.2(4.11), 8.0(4.5), 8.1(1.100), 8.2(1)50
Troubleshooting High CPU related to Dispatch Unit
In short, dispatch unit is the process that processes traffic. In general when this is high it means that traffic is overwhelming the firewall and the firewall can’t keep up. This could be due to too much traffic hitting a specific ACL, policy, class or other ASP drop reason.
If you have a high CPU due to dispatch unit you first must identify what traffic is causing this. If you normally don’t have a high CPU then it shouldn’t be too hard to identify what traffic is causing this problem.
Let’s start by examining the following show commands:
Do you see any input or output errors? If so, take a look at the meaning of interface counters post to determine what the drops are.
Does any interface have an unusually high amount of packets/bytes going through it?
Does any stat seem crazy high?
Are any of the inspects rising very quickly?
Another thing to use is Splunk or a syslog collector to determine what is happening on the device. If you are using Splunk to collect logs from this ASA you could do a search like so:
<ASA-IP> | stats count by error_code event_desc | sort 10 -count
This will show you something like this:
In the case above you can see that syslog message 419002 is triggering a crazy amount of syslogs. Investigate that syslog message to find what the biggest traffic flow is that is responsible for that. You could do a Splunk search like so:
<ASA-IP> error_code="419002" | stats count by src_ip dest_ip dest_port | sort -count
With a search like that you may get a result like this:
Now you know that the flow between
10.100.100.1 is doing a large amount of SYN flooding. Try shunning that source IP for a while to see if traffic dies down. Or find the offending user and tell them to stop.