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 frame and flow sections are separate counter domains. Their names alone do not tell you whether a connection was established or which feature caused the drop. In the follow-up ASAv 9.24(1) lab below, DNS inspection reasons appear under frame, while NAT reverse-path failure appears under flow. Ask for the sections separately and read the exact reason:

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:

• Frame drops dominate: Start with the reasons shown, then check the relevant ACL, route, uRPF, adjacency or inspection policy. The follow-up lab's DNS inspection drops appear here too.
• Flow drops dominate: Read the reason and compare the connection, inspection and NAT state. The follow-up lab's nat-rpf-failed counter appears here, so this section does not by itself prove an established connection failed mid-stream.

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.

Seeing tcp-not-syn on SYN-ACKs that arrive on the outside interface? That is the classic asymmetric-routing signature: the client's SYN went around the firewall and only the reply came through. The ASA TCP state bypass vs asymmetric routing lab reproduces it on ASAv and compares fixing the route with a scoped tcp-state-bypass policy.

Lab: Six ASP Drop Reasons Tested on ASAv 9.24(1)

A second, separate run in my home lab on ASAv 9.24(1) tested the four reasons above, DNS inspection drops and NAT reverse-path failure. Each fault had its own cleared counters and real traffic. Five requested reason names appeared exactly. The sixth, inspect-dns-pak, was absent from this image's reason selector; the DNS tests produced two more specific names instead.

Topology and working baseline

The three-node lab used one ASAv and two Alpine Linux 3.24.2 endpoints. These addresses belong to this test, separate from the earlier Kali lab:

The outside endpoint supplied HTTP on TCP/8000 and a DNS control service on UDP/53. The ASA routed 203.0.113.0/24 through 198.51.100.10, with no default route. Both data ACLs permitted IP in this isolated baseline, and the active global policy, LAB_POLICY, inspected ICMP. Data-path NAT was added only for the NAT test.

Routed ping, HTTP and valid DNS worked before the faults. If you are building the appliance first, start with ASAv boot and first packet. The inside/outside/DMZ walkthrough covers the larger three-zone design.

Clear, send real traffic, then simulate

Each run applied one fault, cleared connections and ASP counters, and recorded a baseline. Endpoint captures watched both eth1 data links. The test then sent three real probe packets and saved show asp drop, interface counters and the relevant ACL, NAT or inspection state. Packet-tracer came after that snapshot, where it could help explain the result. The fault was removed and working traffic checked before the next test.

For example, this is the ASA privileged-EXEC baseline immediately before the NAT probe, excerpted from the recorded session:

asa# clear asp drop
clear asp drop
asa# show asp drop
show asp drop

Frame drop:

Last clearing: 19:34:42 UTC Oct 17 2026 by admin

Flow drop:

Last clearing: 19:34:42 UTC Oct 17 2026 by admin

An empty section here means no nonzero reason rows were printed after clearing. Interface counters and service-policy counters were cumulative, so those required before/after comparisons of their own.

The first four familiar reasons were isolated rather than mixed in one traffic burst. For example, the spoofed-source test produced this frame counter:

Frame drop:
  Reverse-path verify failed (rpf-violated)                                    3

For the route fault, the exact ASA configuration-mode change was:

no route outside 203.0.113.0 255.255.255.0 198.51.100.10 1

The connected outside subnet remained reachable; only the loopback's route was missing. Restoring that same route through 198.51.100.10 returned the routed control traffic to normal.

DNS: use the reason names the image actually exposes

The captured show asp drop frame ? help listed these DNS selectors, among others:

  inspect-dns-invalid-pak                        DNS Inspect invalid packet
  inspect-dns-opt-format-error                   DNS Inspect Multiple OPT Record
  inspect-dns-out-of-app-id                      DNS Inspect out of app id
  inspect-dns-pak-too-long                       DNS Inspect packet too long

There was no exact inspect-dns-pak selector or emitted counter. inspect-dns-pak-too-long is a complete, separate reason name. Treating the shared prefix as an aggregate would invent a counter the test never observed.

The DNS policy was configured with protocol enforcement and a 512-byte maximum, then attached to the active lab policy. These are the recorded configuration commands:

configure terminal
policy-map type inspect dns LAB_DNS
parameters
message-length maximum 512
protocol-enforcement
exit
exit
policy-map LAB_POLICY
class LAB_INSPECT
inspect dns LAB_DNS
end

The active binding matters. A policy definition by itself does not establish which policy inspected the packets. The repeated evidence used here confirmed Service-policy: LAB_POLICY in show service-policy, with Inspect: dns LAB_DNS. A valid DNS query succeeded under each DNS test policy before another counter clear and the fault probes.

Three four-byte malformed DNS headers produced:

Frame drop:
  DNS Inspect invalid packet (inspect-dns-invalid-pak)                         3

In a separate cleared run, three well-formed queries with EDNS padding carried 644 bytes of DNS payload each, exceeding the configured 512-byte maximum:

Frame drop:
  DNS Inspect packet too long (inspect-dns-pak-too-long)                       3

Both counters appeared under Frame drop. Inspection-related reasons do not all belong to the flow section. A synthetic UDP packet-tracer would also miss the payload distinction that these real DNS packets establish.

NAT: three packets, six flow-counter increments

For this test, ASA configuration mode added one static mapping:

configure terminal
object network LAB_INSIDE_SERVER
host 192.0.2.10
nat (inside,outside) static 198.51.100.100
end

The outside endpoint then sent three ICMP echo requests to the real inside address, 192.0.2.10, rather than the mapped address, 198.51.100.100. The outside capture recorded three packets with zero capture-kernel drops. Before packet-tracer, the ASA reported:

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

Last clearing: 19:34:42 UTC Oct 17 2026 by admin

Flow drop:
  NAT reverse path failed (nat-rpf-failed)                                     6

Last clearing: 19:34:42 UTC Oct 17 2026 by admin

That is three ingress packets and six increments of a flow counter. The test did not investigate the internal reason for the multiplier. It does not establish six dropped packets, and the accompanying frame and flow values should not be added into a packet total.

Now run packet-tracer input outside icmp 198.51.100.10 8 0 192.0.2.10 detailed at the ASA privileged prompt. The recorded trace allowed the named outside ACL:

Phase: 2
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Elapsed time: 13396 ns
Config:
access-group OUTSIDE_IN in interface outside
access-list OUTSIDE_IN extended permit ip any any 

It failed later, at NAT's reverse-path check:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: DROP
Elapsed time: 8274 ns
Config:
object network LAB_INSIDE_SERVER
 nat (inside,outside) static 198.51.100.100

Yet the final result still named acl-drop:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Time Taken: 178876 ns
Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_sp_handle_flow_drop:4333 flow (NA)/NA

Here, changing the outside ACL would miss the cause. The failing NAT / rpf-check phase, the static mapping and the real-traffic nat-rpf-failed flow counter explain the denial together. In this same recording, the subsequent single tracer changed the frame total from 3 to 4 and the flow total from 6 to 8. Mixing that simulation into the earlier measurement would overstate the real traffic.

The mapped-address control succeeded from the outside endpoint. Running ping -I 198.51.100.10 -c 3 -W 1 198.51.100.100 there produced:

--- 198.51.100.100 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss

For a different NAT failure, where a stale manual rule wins over the intended mapping, see ASA NAT troubleshooting: fix a stale manual rule. Follow the selected translation and failing phase before editing an ACL.

Verify recovery with real traffic

After the faults were removed, the final recorded checks returned 3/3 routed ping replies, HTTP 200 from 198.51.100.10:8000 and a valid DNS response. DNS inspection and the test static mapping had been removed, leaving the baseline ICMP policy active.

None of the requested target counters rose after the final clear and controls. The frame section did contain one unrelated l2_acl increment whose cause was not isolated; the flow section was empty. Recovery here means the control traffic worked and the target reasons stayed absent. Record that distinction alongside the counter snapshot, then use packet-tracer to explain any remaining failure.

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 and flow are separate counter domains. Read the exact reason: this follow-up lab records DNS inspection drops under frame and nat-rpf-failed under flow.
• 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.
• In the original four-fault test, four counters and nine captured packets were matched to the commands 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.