You will have destinations and ports which should be enough to pinpoint misconfigured application. Ideally, you need to go to the source and remove the invalid configuration.
#Cisco asa show license command how to#
Traffic was following default route taking it to ASA, ASA in turn was sending it back to inside, because of RC 1812 routing, creating a routing loop.Īt this point, you need to decide how to fix it. Then I’ve correlated destinations with valid subnets and found out that most of them did not exist. I got a big list and started with highest talkers first. 1 is destination interface, 2 source interface, 3 huge number of bytes.Ĭopy output and paste it in Excel, do T ext to Columns and sort by most bytes. If for example connection ingress/egress is inside interface then modify the command as s how conn all | inc inside.*inside. Once confirmed modify command to reflect the interface in question. On the packet capture TTL will be decreasing if it is a routing loop. To confirm validate destination network or do packet capture.Īsa# capture 1 interface inside match udp host src_ip host dst_ip If they are the same it may indicate a routing loop which is driving your CPU. Pick a few and look for ingress/egress interfaces. There will be a lot of data but the goal is to find connections with the most bytes. First thing to check is you connection stats with show conn all command.
So next step is troubleshooting Datapath issues.
In my example I had pptp inspection configured in 3 different policies and applied to 3 interfaces including global. CP processing issue was related to duplicate configuration command in policy-map. Unfortunately, there is no cpu history command to go back in time. This gives you a clear indication of a problem. I’ve checked online and there are many articles describing different causes for high CPU on ASA but I do not think this one was covered.ĬPU utilization for 5 seconds = 75% 1 minute: 73% 5 minutes: 73% However, when I looked at CPU utilization on ASA (with FirePOWER off the policy-map) it was still sitting between 70-80%. At first I blamed it on FirePOWER module and of course disabling it fixed the issue. Came across this issue where application performance was poor and pings were hitting 500ms.