<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Cisco ASA 5545-X High CPU usage in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015838#M145074</link>
    <description>&lt;P&gt;Hi guys,&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Today i had a big problem with 2 Cisco ASA 5545-X with fire power services in active/standby mode. These are the perimeter firewalls.&lt;/P&gt;
&lt;P&gt;The active firewall had a high CPU usage of 99%.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;After working with Cisco TAC, it was identified that there was a loop between the active firewall and our internal firewall (Cisco 5585-X). For some reason, the internal firewall had a connection in the connection table that was pointing to the perimeter firewall instead of the correct interface.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;The question that i have is how was this able to happen? Was wondering if this happened to anyone else so that we would be able to stop it from happening again.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Essentially what was happening is that the Perimeter firewall would send the traffic to the internal firewall and the internal firewall would then send the traffic back to the Perimeter firewall and so on.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;See below for technical description:&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;HARDWARE/SOFTWARE: ASA5545 // ASA 9.4(2)11&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;SYMPTOMS: ASA experiencing 99% of CPU usage&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Checked CPU and the process with the highest consumption was DATAPATH-1988:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Perimeter01/act# sh cpu&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;CPU utilization for 5 seconds = 91%; 1 minute: 92%; 5 minutes: 96%&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Perimeter01/act# show proc cpu-us&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Perimeter01/act# show proc cpu-usage sorted non&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;PC&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Thread&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 5Sec&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 1Min&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 5Min&amp;nbsp;&amp;nbsp; Process&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp; -&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 91.9%&amp;nbsp;&amp;nbsp;&amp;nbsp; 88.5%&amp;nbsp;&amp;nbsp;&amp;nbsp; 91.3%&amp;nbsp;&amp;nbsp; DATAPATH-0-1988&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x0000000000832066&amp;nbsp;&amp;nbsp; 0x00007fffdb41d4a0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.3%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.5%&amp;nbsp;&amp;nbsp; CP Processing&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x0000000000976bf3&amp;nbsp;&amp;nbsp; 0x00007fffdb417da0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp; fover_health_monitoring_thread&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000098e7fa&amp;nbsp;&amp;nbsp; 0x00007fffdb418fc0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp; fover_ip&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000148bcf0&amp;nbsp;&amp;nbsp; 0x00007fffdb317d60&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.7%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp; Unicorn Admin Handler&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000148bcf0&amp;nbsp;&amp;nbsp; 0x00007fffdb3f90a0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.7%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp; Unicorn Admin Handler&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000174f4f4&amp;nbsp;&amp;nbsp; 0x00007fffdb413c60&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp; qos_metric_daemon&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] Threat-detection was enabled so, we access the ASA through ASDM and found that a lot of ICMP and ESP traffic was passing through the ASA and the following IPs were involved:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;67.210.X.X&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;67.210.X.X&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;10.X.X.X&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] We decided to shun these IP address, but CPU dropped only from 99% to 88%&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] Looked at interfaces' errors and found that overruns were increasing in the GigabitEthernet 0/6 &amp;amp; 0/7 which are being used for Portchannel 12 which had both outside interfaces&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] We took a show tech of the ASA and found the following issues:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;+ High probability of traffic loop on an interface&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;+ CPU hogs due to SNMP polling&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Took 2 "show conn" outputs with 1 minute apart to see which were the top talkers and found the following:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Total estimated byte count diff: 3,839,427,079.00 bytes&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Top talker connections connections&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 176,124,544.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 134.159.159.138:3016&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 134,772,672.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 134.159.159.138:3017&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 129,737,776.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 183.232.164.41:2156&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 97,058,360.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 203.205.176.12:6966&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 92,321,728.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 202.41.225.22:26592&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;We configured a packet capture and confirmed that these traffic flows were in a loop, so we checked the internal FW and found that these packets should be sent to another interface instead of sending them back to the affected ASA but this ASA had a connection that stated the opposite (for the three internal hosts):&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;INTERNET/DMZ: 10.X.X.X/0 INTERNET/DMZ: 134.159.159.138/3017,&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; , flags&amp;nbsp; , idle 0s, uptime 20h5m, timeout 2s, bytes 937721152&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;ICMP INTERNET/DMZ: 10.X.X.X/0 INTERNET/DMZ: 134.159.159.138/3016,&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; , flags&amp;nbsp; , idle 0s, uptime 20h5m, timeout 2s, bytes 3519536512&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;So these connections for the three internal hosts and after that we saw the CPU dropped to 37% in the external FW.&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Tue, 12 Mar 2019 09:12:22 GMT</pubDate>
    <dc:creator>Davion Stewart</dc:creator>
    <dc:date>2019-03-12T09:12:22Z</dc:date>
    <item>
      <title>Cisco ASA 5545-X High CPU usage</title>
      <link>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015838#M145074</link>
      <description>&lt;P&gt;Hi guys,&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Today i had a big problem with 2 Cisco ASA 5545-X with fire power services in active/standby mode. These are the perimeter firewalls.&lt;/P&gt;
&lt;P&gt;The active firewall had a high CPU usage of 99%.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;After working with Cisco TAC, it was identified that there was a loop between the active firewall and our internal firewall (Cisco 5585-X). For some reason, the internal firewall had a connection in the connection table that was pointing to the perimeter firewall instead of the correct interface.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;The question that i have is how was this able to happen? Was wondering if this happened to anyone else so that we would be able to stop it from happening again.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;Essentially what was happening is that the Perimeter firewall would send the traffic to the internal firewall and the internal firewall would then send the traffic back to the Perimeter firewall and so on.&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P&gt;See below for technical description:&lt;/P&gt;
&lt;P&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;HARDWARE/SOFTWARE: ASA5545 // ASA 9.4(2)11&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;SYMPTOMS: ASA experiencing 99% of CPU usage&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Checked CPU and the process with the highest consumption was DATAPATH-1988:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Perimeter01/act# sh cpu&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;CPU utilization for 5 seconds = 91%; 1 minute: 92%; 5 minutes: 96%&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Perimeter01/act# show proc cpu-us&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Perimeter01/act# show proc cpu-usage sorted non&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;PC&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Thread&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 5Sec&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 1Min&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 5Min&amp;nbsp;&amp;nbsp; Process&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp; -&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; -&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 91.9%&amp;nbsp;&amp;nbsp;&amp;nbsp; 88.5%&amp;nbsp;&amp;nbsp;&amp;nbsp; 91.3%&amp;nbsp;&amp;nbsp; DATAPATH-0-1988&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x0000000000832066&amp;nbsp;&amp;nbsp; 0x00007fffdb41d4a0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.3%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.5%&amp;nbsp;&amp;nbsp; CP Processing&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x0000000000976bf3&amp;nbsp;&amp;nbsp; 0x00007fffdb417da0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp; fover_health_monitoring_thread&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000098e7fa&amp;nbsp;&amp;nbsp; 0x00007fffdb418fc0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp; &amp;nbsp;0.1%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.1%&amp;nbsp;&amp;nbsp; fover_ip&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000148bcf0&amp;nbsp;&amp;nbsp; 0x00007fffdb317d60&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.7%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp; Unicorn Admin Handler&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000148bcf0&amp;nbsp;&amp;nbsp; 0x00007fffdb3f90a0&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.7%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp; Unicorn Admin Handler&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;0x000000000174f4f4&amp;nbsp;&amp;nbsp; 0x00007fffdb413c60&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.0%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 0.6%&amp;nbsp;&amp;nbsp; qos_metric_daemon&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] Threat-detection was enabled so, we access the ASA through ASDM and found that a lot of ICMP and ESP traffic was passing through the ASA and the following IPs were involved:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;67.210.X.X&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;67.210.X.X&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;10.X.X.X&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] We decided to shun these IP address, but CPU dropped only from 99% to 88%&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] Looked at interfaces' errors and found that overruns were increasing in the GigabitEthernet 0/6 &amp;amp; 0/7 which are being used for Portchannel 12 which had both outside interfaces&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;[] We took a show tech of the ASA and found the following issues:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;+ High probability of traffic loop on an interface&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;+ CPU hogs due to SNMP polling&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Took 2 "show conn" outputs with 1 minute apart to see which were the top talkers and found the following:&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Total estimated byte count diff: 3,839,427,079.00 bytes&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;Top talker connections connections&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 176,124,544.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 134.159.159.138:3016&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 134,772,672.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 134.159.159.138:3017&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 129,737,776.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 183.232.164.41:2156&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 97,058,360.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 203.205.176.12:6966&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 92,321,728.00 bytes&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ICMP INTERNET/DMZ 10.X.X.X:0 INTERNET/DMZ 202.41.225.22:26592&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;We configured a packet capture and confirmed that these traffic flows were in a loop, so we checked the internal FW and found that these packets should be sent to another interface instead of sending them back to the affected ASA but this ASA had a connection that stated the opposite (for the three internal hosts):&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;INTERNET/DMZ: 10.X.X.X/0 INTERNET/DMZ: 134.159.159.138/3017,&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; , flags&amp;nbsp; , idle 0s, uptime 20h5m, timeout 2s, bytes 937721152&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;ICMP INTERNET/DMZ: 10.X.X.X/0 INTERNET/DMZ: 134.159.159.138/3016,&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp; , flags&amp;nbsp; , idle 0s, uptime 20h5m, timeout 2s, bytes 3519536512&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;&lt;/SPAN&gt;&lt;/P&gt;
&lt;P class="x_MsoNormal"&gt;&lt;SPAN&gt;So these connections for the three internal hosts and after that we saw the CPU dropped to 37% in the external FW.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 12 Mar 2019 09:12:22 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015838#M145074</guid>
      <dc:creator>Davion Stewart</dc:creator>
      <dc:date>2019-03-12T09:12:22Z</dc:date>
    </item>
    <item>
      <title>It will be a software bug.  I</title>
      <link>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015839#M145075</link>
      <description>&lt;P&gt;It will be a software bug. &amp;nbsp;I would upgrade to a gold star release like&amp;nbsp;&lt;SPAN&gt;asa944-5-smp-k8.bin.&lt;/SPAN&gt;&lt;/P&gt;
&lt;P&gt;&lt;SPAN&gt;&lt;A href="https://software.cisco.com/download/release.html?mdfid=284143130&amp;amp;catid=268438162&amp;amp;softwareid=280775065&amp;amp;release=9.4.4%20Interim&amp;amp;relind=AVAILABLE&amp;amp;rellifecycle=&amp;amp;reltype=latest"&gt;https://software.cisco.com/download/release.html?mdfid=284143130&amp;amp;catid=268438162&amp;amp;softwareid=280775065&amp;amp;release=9.4.4%20Interim&amp;amp;relind=AVAILABLE&amp;amp;rellifecycle=&amp;amp;reltype=latest&lt;/A&gt;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 11 Apr 2017 04:20:34 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015839#M145075</guid>
      <dc:creator>Philip D'Ath</dc:creator>
      <dc:date>2017-04-11T04:20:34Z</dc:date>
    </item>
    <item>
      <title>Hmm well will give feedback</title>
      <link>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015840#M145076</link>
      <description>&lt;P&gt;Hmm well will give feedback once i finish working with Cisco TAC on the issue&lt;/P&gt;</description>
      <pubDate>Wed, 12 Apr 2017 04:20:08 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3015840#M145076</guid>
      <dc:creator>Davion Stewart</dc:creator>
      <dc:date>2017-04-12T04:20:08Z</dc:date>
    </item>
    <item>
      <title>Re: Hmm well will give feedback</title>
      <link>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3958893#M145077</link>
      <description>&lt;P&gt;I am experiencing the same thing on ASA 5545-x&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Cisco Adaptive Security Appliance Software Version 8.6(1)2&lt;BR /&gt;Device Manager Version 6.6(1)&lt;/P&gt;&lt;P&gt;Compiled on Fri 01-Jun-12 02:16 by builders&lt;BR /&gt;System image file is "disk0:/asa861-2-smp-k8.bin"&lt;BR /&gt;Config file at boot was "startup-config"&lt;/P&gt;&lt;P&gt;CSCSASA-1 up 210 days 0 hours&lt;/P&gt;&lt;P&gt;Hardware: ASA5545, 12288 MB RAM, CPU Lynnfield 2660 MHz, 1 CPU (8 cores)&lt;BR /&gt;ASA: 6144 MB RAM, 1 CPU (1 core)&lt;BR /&gt;Internal ATA Compact Flash, 8192MB&lt;/P&gt;&lt;P&gt;SCSASA-1# sh cpu usage&lt;BR /&gt;CPU utilization for 5 seconds = 99%; 1 minute: 99%; 5 minutes: 99%&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;SCSASA-1# sh processes cpu-usage sorted non-zero&lt;BR /&gt;PC Thread 5Sec 1Min 5Min Process&lt;BR /&gt;- - 95.6% 95.6% 95.6% DATAPATH-0-1417&lt;BR /&gt;0x00000000013382a4 0x00007ffebb728b58 2.5% 2.5% 2.5% Logger&lt;BR /&gt;0x00000000006c27c2 0x00007ffebb71d6f8 1.1% 1.1% 1.1% CP Processing&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 14 Nov 2019 20:30:40 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3958893#M145077</guid>
      <dc:creator>John Eze</dc:creator>
      <dc:date>2019-11-14T20:30:40Z</dc:date>
    </item>
    <item>
      <title>Re: Cisco ASA 5545-X High CPU usage</title>
      <link>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3958896#M145079</link>
      <description>&lt;P&gt;please do share finding once the issue is fixed. this issue seem very interesting and informative. apologies you do not want to hear this but you explain the problem very well.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Thu, 14 Nov 2019 20:36:01 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/cisco-asa-5545-x-high-cpu-usage/m-p/3958896#M145079</guid>
      <dc:creator>Sheraz.Salim</dc:creator>
      <dc:date>2019-11-14T20:36:01Z</dc:date>
    </item>
  </channel>
</rss>

