The Cisco ASA's accelerated security path (ASP) is the data-plane fast path that handles every forwarded packet after a flow has been admitted. When the ASP drops a packet, the reason it cites in show asp drop is your single most useful diagnostic on a working firewall. There is no syslog for most ASP drops, no debug, no ACL hit counter - just an internal counter that increments and a one-line label. This article decodes the most common drop reasons, walks through the lab evidence behind each, and shows how to chain show asp drop with an asp-drop type capture to see the actual packets being discarded. All output below is from the live ASAv 9.23(1) in the PingLabz ASA reference lab.
If you are about to draft an ASA ACL troubleshooting ticket or you suspect a NAT path is silently failing, run show asp drop first. About 70% of "the firewall is broken" cases resolve to a counter that explains exactly what the ASA was doing. The other 30% need a packet capture to confirm.
show asp drop: The Counter Dump
The base command lists every drop reason that has incremented since last clear, separated into frame drops (per-packet, classification-time) and flow drops (per-flow, midstream). From the lab:
ASA-PERIM# show asp drop
Frame drop:
No valid adjacency (no-adjacency) 40
No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop. (no-v4-adjacency) 5
Flow is denied by configured rule (acl-drop) 1606
FP L2 rule drop (l2_acl) 19
Interface is down (interface-down) 3
IKE new SA limit exceeded (ike-sa-rate-limit) 3
Last clearing: Never
Flow drop:
Need to start IKE negotiation (need-ike) 14
Last clearing: Never
Six frame drop reasons, one flow drop reason. Each is a real signal. Let's read them.
acl-drop: Flow is Denied by Configured Rule
1606 hits is by far the largest counter, and it is exactly what it says: 1606 packets matched a deny statement (explicit or implicit) on an interface ACL. To find which rule:
ASA-PERIM# show access-list OUTSIDE_IN | begin OUTSIDE_IN
access-list OUTSIDE_IN; 5 elements; name hash: 0xe01d8199
access-list OUTSIDE_IN line 1 extended deny tcp host 198.51.100.99 any (hitcnt=1) (Last Hit=00:01:09 UTC May 10 2026)
access-list OUTSIDE_IN line 2 extended permit tcp any object DMZ-WEB eq www (hitcnt=1) (Last Hit=23:27:41 UTC May 9 2026)
access-list OUTSIDE_IN line 3 extended permit tcp any object DMZ-WEB eq https (hitcnt=2) (Last Hit=00:01:09 UTC May 10 2026)
access-list OUTSIDE_IN line 4 extended permit icmp any object DMZ-WEB (hitcnt=2) (Last Hit=01:55:20 UTC May 10 2026)
access-list OUTSIDE_IN line 5 extended deny ip any any log informational interval 300 (hitcnt=59) (Last Hit=01:55:47 UTC May 10 2026)
The asp-drop counter (1606) and the explicit-deny ACL counter (59 on line 5) do not match because asp-drop catches everything denied anywhere on the data path, not just by named ACLs. ASP also counts: implicit deny on un-applied directions, asp-table denies for unknown protocols, and out-of-state drops that classify as ACL on the way down. Use ACL counters to identify a deny line; use asp-drop to confirm the magnitude.
To see the actual packets being denied, attach a capture:
ASA-PERIM# capture ASP-DROP type asp-drop acl-drop
ASA-PERIM# show capture ASP-DROP packet-number 100
342 packets captured
100: 01:55:07.071498 203.0.113.1.58279 > 198.51.100.10.1967: udp 52 Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: frame snp_classify_table_lookup:6044 flow (NA)/NA
1 packet shown
That gives you the source, destination, port, and timestamp of every dropped packet. From there it is one show access-list away from the rule that fired.
no-adjacency and no-v4-adjacency
"No valid adjacency" is what an ASA says when it has a route to a destination but cannot resolve the next-hop. The two flavors:
| Counter | Means | Fix |
|---|---|---|
no-adjacency | Generic "I cannot get a layer-2 adjacency for the next-hop". Usually IPv6 or unknown encap. | Check the routing table for the destination, then verify the next-hop is on a directly-connected interface. |
no-v4-adjacency | Specifically "I cannot ARP for the IPv4 next-hop". The most common case is a missing ARP entry on the egress interface. | show arp on the egress interface; if missing, the downstream device is silent or unreachable. |
The lab's 40 + 5 hits came from two test scenarios. The no-v4-adjacency hits came from packets bound for an alpine host on the DMZ that does not respond to ARP from this side. The 40 generic no-adjacency hits came from IPv6 router-solicitations the ASA had no IPv6 nexthop for.
The diagnostic discipline: when a flow is being silently lost between ingress and egress and packet-tracer says ALLOW, look at show asp drop. If no-v4-adjacency increments while you push test traffic, the next hop is not responding to ARP. show arp, then ping the next hop from the ASA, then look at the downstream device.
interface-down
3 hits in the lab. The reason is exactly what it says: a packet was queued for an egress interface that came down before the packet was sent. Three packets in flight when the interface flapped. This counter is more useful than it looks - if it is climbing while no interfaces are obviously flapping, you have a transient layer-1 problem on one of the data interfaces. Pair with show interface looking at output discards.
l2_acl: FP L2 Rule Drop
19 hits. This is a layer-2-classifier drop, fired before the layer-3 ACL ever runs. The most common cause is a packet hitting an interface that is not the one its source MAC is associated with - which is usually a result of MAC address aging plus an asymmetric path - or a layer-2 EtherType the ASA does not pass by default (IS-IS frames, custom protocols). It can also be a real loop that the ASA is breaking. Look at show interface | include MAC|input rate on neighbors and show conn detail for any flow showing this counter increment alongside.
ike-sa-rate-limit and need-ike
The two IKE-related counters that show in the lab. These are VPN data-path drops:
ike-sa-rate-limit: 3 hits. The control-plane received more new IKE_SA_INIT requests in a window than the configured rate limit allows. Defaults are usually fine; if this counter climbs, you have an attacker probing UDP/500 or a misbehaving peer reinitating constantly. Mitigation:crypto ikev2 limit max-sa-init-rate <n>.need-ike(flow drop): 14 hits. A packet matched a crypto map's interesting traffic but the IKE_SA was not yet established. The ASA queues the packet briefly, fires off IKE negotiation, and drops the packet if negotiation does not complete in time. 14 hits across a few hours is a normal background level, especially right after a reboot or a tunnel flap. Climbing fast = your IKE is failing. See troubleshoot IPsec phases.
show asp drop flow vs show asp drop frame
The split matters. Frame drops happen during initial classification, before a flow is created. Flow drops happen on packets that arrive on an existing flow but are then dropped by an inspection or a rate-limit. To see them separately:
ASA-PERIM# show asp drop frame
No valid adjacency (no-adjacency) 40
No valid V4 adjacency. Check ARP table ... 5
Flow is denied by configured rule (acl-drop) 1606
FP L2 rule drop (l2_acl) 19
Interface is down (interface-down) 3
IKE new SA limit exceeded (ike-sa-rate-limit) 3
Last clearing: Never
ASA-PERIM# show asp drop flow
Need to start IKE negotiation (need-ike) 14
Last clearing: Never
If a single ticket shows large frame counts and small flow counts, the problem is at the door (ACL, ARP, layer-2). If flow counts dominate, the problem is mid-stream (inspection rejecting payload, MTU, asymmetric routing).
Get the Cisco ASA Field Reference - 9 pages, free
Everything you'd want to remember about Cisco ASA on nine printable pages. Per-packet pipeline diagram, NAT 8.3+ section ordering, six-branch troubleshooting decision tree, real lab show-output annotated, paste-ready three-zone config. Free for PingLabz members - just sign up with your email.
show asp event-log: Per-Packet Trace
For per-packet detail beyond the counters, use show asp event dp-cp drop to see the data-plane to control-plane queue and any drop events ASA buffered:
ASA-PERIM# 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
PTP-Traffic Event Queue 0 0
General Event Queue 0 1
Syslog Event Queue 0 4
Non-Blocking Event Queue 0 0
Midpath High Event Queue 0 0
Midpath Norm Event Queue 0 0
Crypto Event Queue 0 0
HA Event Queue 0 0
HA Ctl 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 "high-water" column is the watch column. Anything climbing above 50 indicates the data path is back-pressuring the control plane - typically because of a flood (Threat-Detection queue) or many simultaneous IKE attempts (Crypto queue). On a healthy ASA all values should be 0 most of the time.
Clearing and Trending the Counters
Counters never reset on their own. The default state shows Last clearing: Never, which means the values are cumulative from the last reload. To trend a problem in real time, clear and watch:
ASA-PERIM# clear asp drop
ASA-PERIM# show asp drop
... empty ...
! drive test traffic ...
ASA-PERIM# show asp drop
Frame drop:
Flow is denied by configured rule (acl-drop) 23
23 acl-drops since clearing. Now you know the rate at which they happen, not just the lifetime total. Pair with show clock at clear time and at observation time for an exact rate per minute.
The Reasons You Will See Most
The reasons in this lab are a small subset of what the ASA can drop for. The catalog is large; here are the ten you will see in production most often, with their root cause:
| Reason | Root cause |
|---|---|
acl-drop | Denied by an interface ACL or an implicit deny. |
nat-no-xlate-to-pat-pool | Auto-NAT PAT pool exhausted. Increase the pool or split the source. |
tcp-not-syn | TCP packet arrived for a flow with no existing connection state. Asymmetric routing or stateful violation. |
tcp-bad-flags | TCP flag combination invalid (e.g. SYN+FIN). Often a scanner or broken middlebox. |
no-route | Routing table has no entry for the destination. Look for missing static or dynamic route. |
inspect-icmp-error-no-existing-conn | ICMP unreachable for a flow the ASA has no record of. Inspect-icmp-error is dropping it; remove the inspection if you need this traffic. |
nat-rpf-failed | NAT reverse-path-forwarding check failed. The packet's source IP does not match the NAT direction. |
flow-expired | Packet for a connection that timed out. Symptom of a long-idle flow that the firewall pruned. |
no-adjacency / no-v4-adjacency | Cannot resolve next-hop layer 2. |
need-ike | IKE not yet established for an interesting-traffic match. |
For the comprehensive list, see Cisco's "ASP drop reason" reference. For each reason, the workflow is the same: spot it in show asp drop, attach capture <name> type asp-drop <reason> to see the packet, then fix the upstream cause.
Key Takeaways
show asp drop is the first command to run when the ASA appears to be silently dropping traffic. The frame-drop counters tell you something is being denied at classification time (ACL, adjacency, interface state, layer-2 classifier). The flow-drop counters tell you something is being killed mid-stream (IKE, inspection). Pair the counter that increments with a matching capture <name> type asp-drop <reason> to see the offending packets, then chase the upstream cause. The full Cisco ASA reference cluster has the rest of the operational toolkit, including CLI packet capture, conn / xlate troubleshooting, and common outage scenarios.
