Cisco ASA asp-drop Counters Explained

The Cisco ASA's accelerated security path (ASP) is the data-plane fast path that handles every forwarded packet. When the ASP discards one, there is usually no syslog, no debug and no ACL hit counter to tell you. There is a counter and a one-line label in show asp drop, and that label is the single most useful diagnostic on a firewall that is up but silently eating traffic.

Most articles list the reasons. This one causes them. Four faults were built into a lab ASAv on purpose, one traffic generator was pointed at it, and every counter that moved was matched to the exact packet that moved it using an asp-drop capture. All output below is from a live ASAv running 9.24(1), part of the PingLabz ASA reference cluster.

The Lab, and the Four Deliberate Faults

A minimal firewall: an inside segment with a Kali host on it, an outside segment with a router standing in for the internet, and PAT between them.

ASA1# show nameif
Interface                Name                     Security
GigabitEthernet0/0       outside                    0
GigabitEthernet0/1       inside                   100

ASA1# show interface ip brief
Interface                  IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0         203.0.113.1     YES CONFIG up                    up
GigabitEthernet0/1         10.20.10.1      YES CONFIG up                    up
Internal-Data0/0           169.254.1.1     YES unset  up                    up
Management0/0              unassigned      YES unset  administratively down down

Inside is 10.20.10.0/24 with the attacker host at 10.20.10.101. Outside is 203.0.113.0/24, and the router out there owns 8.8.8.8/32 so there is one destination that genuinely works. Four things were then made deliberately wrong:

ASA1# show run access-list
access-list INSIDE-IN extended permit icmp any4 any4
access-list INSIDE-IN extended permit tcp any4 host 8.8.8.8 eq www

ASA1# show run | include verify
ip verify reverse-path interface inside

Start From Zero

The counters are cumulative since the last reload, so the first thing to do in any investigation is establish a baseline. clear asp drop costs nothing and turns a meaningless lifetime total into a rate you can reason about.

ASA1# clear asp drop
ASA1# show asp drop

Frame drop:

Last clearing: 20:47:06 UTC Aug 29 2026 by enable_15

Flow drop:

Last clearing: 20:47:06 UTC Aug 29 2026 by enable_15

ASA1# show clock
20:47:07.222 UTC Sat Aug 29 2026

Note the Last clearing line changing from Never to a timestamp and a user. Write the clock down. Everything after this is measured against it.

One Command Per Drop Reason

From the Kali host on the inside, six commands in about seventy seconds. The first one is the control: it should work.

j@kali:~$ ping -c 3 -W 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=255 time=8.21 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=255 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=255 time=5.62 ms
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

j@kali:~$ ping -c 3 -W 1 198.51.100.9
3 packets transmitted, 0 received, 100% packet loss, time 2047ms

j@kali:~$ nc -z -w 2 8.8.8.8 443
j@kali:~$ sudo hping3 -a 172.16.9.9 -1 -c 3 8.8.8.8
j@kali:~$ sudo hping3 -S -F -p 80 -c 3 8.8.8.8
j@kali:~$ sudo hping3 -A -p 80 -c 3 8.8.8.8

ICMP to 8.8.8.8 goes through: permitted by the ACL, a route exists, PAT translates it. Everything after that is a different kind of wrong. Here is what the firewall recorded:

ASA1# show asp drop

Frame drop:
  No route to host (no-route)                                                  3
  Reverse-path verify failed (rpf-violated)                                    3
  Flow is denied by configured rule (acl-drop)                                 1
  First TCP packet not SYN (tcp-not-syn)                                       6

Last clearing: 20:47:06 UTC Aug 29 2026 by enable_15

ASA1# show clock
20:48:16.942 UTC Sat Aug 29 2026

Four counters, and the arithmetic lines up with what was sent. Three pings to an unrouted address became three no-route. Three spoofed ICMP packets became three rpf-violated. One nc attempt sent one SYN and produced one acl-drop. Three SYN+FIN packets plus three bare ACKs became six tcp-not-syn.

That is the whole discipline in one screen. You do not read show asp drop in isolation. You clear it, cause something, and read the difference.

Prove It With an asp-drop Capture

Counters tell you a reason fired. They do not tell you which packet fired it, and on a real firewall with real traffic that gap is where the guessing starts. The ASA closes it: you can capture the dropped packets themselves, with the reason attached to each one.

ASA1# clear asp drop
ASA1# capture ASPDROP type asp-drop all buffer 1000000
ASA1# show capture
capture ASPDROP type asp-drop all buffer 1000000 [Capturing - 0 bytes]

The same six commands were then run again from Kali, two packets each instead of three. The counters moved as expected:

ASA1# show asp drop

Frame drop:
  No route to host (no-route)                                                  2
  Reverse-path verify failed (rpf-violated)                                    2
  Flow is denied by configured rule (acl-drop)                                 1
  First TCP packet not SYN (tcp-not-syn)                                       4

Last clearing: 20:48:55 UTC Aug 29 2026 by enable_15

And here is what those nine packets actually were:

ASA1# show capture ASPDROP
Target:     OTHER
Hardware:   ASAv
Cisco Adaptive Security Appliance Software Version 9.24(1)

9 packets captured

   1: 20:49:25.069286  10.20.10.101 > 198.51.100.9 icmp: echo request Drop-reason: (no-route) No route to host, Drop-location: frame snp_sp_ingress:7117 flow (NA)/NA

   2: 20:49:26.080104  10.20.10.101 > 198.51.100.9 icmp: echo request Drop-reason: (no-route) No route to host, Drop-location: frame snp_sp_ingress:7117 flow (NA)/NA

   3: 20:49:27.090479  10.20.10.101.60530 > 8.8.8.8.443: S 3859415825:3859415825(0) win 64240 <mss 1460,sackOK,timestamp 1438569083 0,nop,wscale 10> Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

   4: 20:49:27.116372  172.16.9.9 > 8.8.8.8 icmp: echo request Drop-reason: (rpf-violated) Reverse-path verify failed, Drop-location: frame snp_sp_ingress:7117 flow (NA)/NA

   5: 20:49:27.417046  172.16.9.9 > 8.8.8.8 icmp: echo request Drop-reason: (rpf-violated) Reverse-path verify failed, Drop-location: frame snp_sp_ingress:7117 flow (NA)/NA

   6: 20:49:28.468832  10.20.10.101.1954 > 8.8.8.8.80: SF 446772184:446772184(0) win 512 Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7510 flow (NA)/NA

   7: 20:49:28.769186  10.20.10.101.1955 > 8.8.8.8.80: SF 435372362:435372362(0) win 512 Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7510 flow (NA)/NA

   8: 20:49:28.824496  10.20.10.101.1954 > 8.8.8.8.80: . ack 868598258 win 512 Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7510 flow (NA)/NA

   9: 20:49:29.125100  10.20.10.101.1955 > 8.8.8.8.80: . ack 348841480 win 512 Drop-reason: (tcp-not-syn) First TCP packet not SYN, Drop-location: frame snp_sp:7510 flow (NA)/NA

9 packets shown

Every line carries the source, the destination, the ports, the TCP flags, the timestamp, the reason, and the exact function inside the ASP that made the call. Packet 3 is the nc attempt to port 443, dropped at snp_classify_table_lookup, which is ACL classification. Packets 4 and 5 still carry the spoofed 172.16.9.9 source. Packets 6 and 7 show SF, the SYN+FIN combination no legitimate stack sends.

Read the Drop-location too. snp_sp_ingress means the packet died on the way in, before classification. snp_classify_table_lookup means it died at the ACL. snp_sp means it got as far as the security policy. When two reasons could explain a symptom, the location tells you how far the packet actually got.

The ACL Counter Will Not Match, and That Is the Lesson

Here is the trap that sends people down the wrong path. Look at the ACL after that run:

ASA1# show access-list INSIDE-IN
access-list INSIDE-IN; 2 elements; name hash: 0xf1656621
access-list INSIDE-IN line 1 extended permit icmp any4 any4 (hitcnt=3) (Last Hit=20:47:45 UTC Aug 29 2026)
access-list INSIDE-IN line 2 extended permit tcp any4 host 8.8.8.8 eq www (hitcnt=10) (Last Hit=20:49:28 UTC Aug 29 2026)

Line 2 shows 10 permit hits. The capture above shows four of those same packets being dropped anyway, as tcp-not-syn, milliseconds later. The ACL said yes. The TCP state check said no.

This is why "but the ACL permits it" is never a conclusion. An ACL permit gets a packet past one stage of the ASP and no further. If you are troubleshooting an ASA ACL problem and the hit counters look healthy while traffic still fails, the ASP is telling you the failure is downstream of the ACL, and show asp drop is where it says so.

Frame Drops Versus Flow Drops

The split at the top of the output is not cosmetic. Frame drops happen during classification, before a connection exists. Flow drops happen to packets on a connection that already exists, killed by an inspection, a rate limit or a timeout. Ask for them separately:

ASA1# show asp drop frame
  No route to host (no-route)                                                  2
  Reverse-path verify failed (rpf-violated)                                    2
  Flow is denied by configured rule (acl-drop)                                 1
  First TCP packet not SYN (tcp-not-syn)                                       4

Last clearing: 20:48:55 UTC Aug 29 2026 by enable_15

ASA1# show asp drop flow

Last clearing: 20:48:55 UTC Aug 29 2026 by enable_15

Flow drops: none. Every one of the four faults is a door problem, not a mid-stream problem, and the ASA classifies them that way without being asked. That split is a fast triage signal:

Turning a Counter Into a Rate

A total is not a diagnosis. A five-figure acl-drop count could be a year of background noise or a scan happening right now, and the counter alone cannot tell you which. Clear, cause, read the clock:

ASA1# clear asp drop
ASA1# capture ACLDROP type asp-drop acl-drop buffer 500000
ASA1# show clock
20:51:00.622 UTC Sat Aug 29 2026

j@kali:~$ sudo nmap -Pn -sS -p 20-45 --max-retries 0 -T4 8.8.8.8
Nmap done: 1 IP address (1 host up) scanned in 0.35 seconds

ASA1# show clock
20:51:33.822 UTC Sat Aug 29 2026
ASA1# show asp drop

Frame drop:
  Flow is denied by configured rule (acl-drop)                                22

Last clearing: 20:50:59 UTC Aug 29 2026 by enable_15

Twenty-two acl-drop in thirty-four seconds, from one twenty-six-port SYN scan. Now the number means something. And because the capture was filtered to a single reason, the buffer holds only what you asked for:

ASA1# show capture ACLDROP packet-number 3
22 packets captured

   3: 20:51:28.339231  10.20.10.101.35025 > 8.8.8.8.25: S 4239521306:4239521306(0) win 1024 <mss 1460> Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6167 flow (NA)/NA

1 packet shown

ASA1# show capture
capture ACLDROP type asp-drop acl-drop buffer 500000 [Capturing - 1628 bytes]

One host, sequential destination ports, tiny window, no payload. That is a scan, and the firewall documented it without a single syslog message. Pair this with a normal interface capture when you need to see what the permitted traffic is doing as well.

Filter the capture, always. type asp-drop all is right when you are exploring and the box is quiet. On a production firewall it will fill the buffer with noise in seconds. Name the reason you are chasing.

When the Counters Say Nothing

If show asp drop is empty and traffic is still failing, the packets are not reaching the ASP, or they are being dropped somewhere that does not count as an ASP drop. Two places to look next. The dp-cp event queues show whether the data path is back-pressuring the control plane:

ASA1# show asp event dp-cp drop
DP-CP EVENT QUEUE                  QUEUE-LEN  HIGH-WATER
Punt Event Queue                           0           0
Routing Event Queue                        0           0
Identity-Traffic Event Queue               0           1
Syslog Event Queue                         0           0
Midpath High Event Queue                   0           1
Midpath Norm Event Queue                   0           2
Crypto Event Queue                         0           0
Threat-Detection Event Queue               0           0
ARP Event Queue                            0           1
TMATCH Event Queue                         0           1

EVENT-TYPE          ALLOC ALLOC-FAIL ENQUEUED ENQ-FAIL  RETIRED 15SEC-RATE
drop-flow               0          0        0        0        0          0

The column that matters is HIGH-WATER, not QUEUE-LEN. Queue length is a snapshot and will almost always read zero. High-water is the worst it has been since boot. Single digits are normal background. A Crypto queue in the hundreds means IKE is being hammered, which is where the IPsec phase troubleshooting path starts. A Threat-Detection queue climbing means a flood.

The other place is NAT. A translation that never happens produces a drop that is easy to misread:

ASA1# show nat detail
Auto NAT Policies (Section 2)
1 (inside) to (outside) source dynamic INSIDE-NET interface
    translate_hits = 3, untranslate_hits = 0
    Source - Origin: 10.20.10.0/24, Translated: 203.0.113.1/24

Three translate hits, matching the three pings that actually worked. Nothing else got far enough to be translated. When translate_hits stays flat while you push test traffic, the packet is dying before NAT, and the ASP counter will tell you where. See conn and xlate troubleshooting for the other half of that story.

The Reasons You Will See Most

Four counters were produced here on purpose. The full catalog runs to hundreds. These are the ones that show up in real tickets, with the cause to chase for each:

Whatever the reason, the workflow is identical: see it in show asp drop, attach capture <name> type asp-drop <reason> to see the packets, then chase the cause the packet points at.

FAQ

Why does the ACL hit count not match the acl-drop counter?

Because they count different things. The ACL counter counts matches on named lines. acl-drop counts everything denied anywhere on the data path, including implicit denies and classification-table denies that no named line ever sees. Use the ACL counters to find the rule, use acl-drop to judge the volume.

Do ASP drops generate syslog messages?

Most do not. That is the whole reason the counters exist and the whole reason people find these drops confusing. An asp-drop capture is the closest thing to a per-packet log you will get.

Is it safe to run clear asp drop in production?

Yes. It resets counters only, it does not touch connections, translations or configuration. The one cost is losing the lifetime totals, so note anything interesting before you clear.

What is the Drop-location field for?

It names the function inside the ASP that discarded the packet, which tells you how far it got. snp_sp_ingress is before classification, snp_classify_table_lookup is at the ACL, snp_sp is at the security policy. When two reasons could explain a symptom, the location breaks the tie.

Can I capture more than one drop reason at once?

type asp-drop all catches every reason, which is right on a quiet box and wrong on a busy one. On production, run one capture per reason you are chasing and keep the buffer small.

Key Takeaways

• show asp drop is the first command on an ASA that is up but silently losing traffic. Most ASP drops produce no syslog at all.
• Counters are cumulative since reload. Clear, cause, read the clock. A lab scan produced 22 acl-drop in 34 seconds, which is a diagnosis. The lifetime total is not.
• capture <name> type asp-drop <reason> turns a counter into evidence: source, destination, ports, flags, timestamp, reason and drop location, per packet.
• An ACL permit is not the last word. In the lab the ACL logged 10 permit hits on the same rule that let four packets through to be dropped as tcp-not-syn milliseconds later.
• Frame drops mean the problem is at the door (ACL, route, uRPF, NAT). Flow drops mean it is mid-stream (inspection, timeout, MTU).
• Read Drop-location, not just Drop-reason. It tells you how far into the ASP the packet survived.
• In show asp event dp-cp drop, watch HIGH-WATER, not QUEUE-LEN. Queue length is almost always zero even when something is badly wrong.
• Four faults, four counters, nine captured packets, all matched to the command that caused them. Do the same on your own box before you need to do it under pressure.

The rest of the operational toolkit lives in the Cisco ASA reference cluster, including CLI packet capture, conn and xlate troubleshooting and common outage scenarios.