pjhtech Tools
Cisco · Cisco IOS XE

Cisco ACL Counters: Verify Rules, Direction and Hardware Drops

Quick answer #

First verify which ACL is attached to the actual forwarding interface and in which direction. Then inspect the rules and relevant counters. On Catalyst 9000, ordinary ACL match counters can omit hardware-processed traffic; a zero in the software view is not proof that the ACL was bypassed.

Scope: IOS XE IPv4 interface ACL inspection, with explicitly separate Catalyst 9000 hardware examples. ISR/ASR/QFP platforms require their own hardware commands. This is not an ASA access-list hit-count reference.

Read-only commands #

Read-only commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only

Replace these example values: GigabitEthernet0/0/0.

show ip interface GigabitEthernet0/0/0
Read-only

Replace these example values: GigabitEthernet0/0/0.

show running-config interface GigabitEthernet0/0/0
Output may contain sensitive operational data.
Read-only

Replace these example values: EDGE-IN.

show ip access-lists EDGE-IN
Read-only

Replace these example values: EDGE-IN.

show access-lists EDGE-IN

Catalyst 9300-style hardware view #

Catalyst 9300-style hardware view
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show platform software fed switch active acl counters hardware

Some Catalyst 9500 platforms use this form instead #

Some Catalyst 9500 platforms use this form instead
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show platform software fed active acl counters hardware

Use the form supported by your exact platform; the extra switch keyword is not universal. These displays provide aggregate hardware statistics, not a guaranteed per-rule packet count.

Workflow #

  1. Describe one flow with source, destination, protocol, ports and direction. For an ICMP problem, record the relevant message type rather than inventing TCP or UDP ports.
  2. Establish the routed path. Locate the interface that the packet actually enters or leaves and inspect its inbound and outbound ACL attachments.
  3. Read the applicable ACL in order. Find the first matching entry, including address wildcards and protocol conditions. An ACL's presence in the configuration does not show that the affected interface uses it.
  4. Save counters before and after a narrowly timed reproduction of the symptom. Preserve existing counters so the change remains reviewable without losing earlier evidence.
  5. On hardware-forwarding switches, correlate the software view with the supported hardware view. Use the interval and other traffic on the switch to judge how strongly an aggregate change relates to your test.

Interpretation pitfalls #

An aggregate drop increase supports further investigation but does not uniquely identify one ACL entry. Shared policies and unrelated traffic can contribute during the same observation interval. The absence of a visible per-entry increment can be a measurement limitation rather than a rule-order problem.

The final implicit denial may not appear as an ordinary numbered entry. Also keep security filtering separate from ACLs used to classify traffic for NAT or another feature: the same permit/deny vocabulary does not make every ACL a packet filter applied to an interface.

Evidence to save #

Keep the flow description, actual attachment and direction, ordered rules and synchronized counter samples together. Do not add broad permits, enable extensive logging or clear shared counters merely to make the diagnosis easier. The first goal is to identify the relevant policy and measurement point accurately.

Useful tools and references #

  • Wildcard mask calculator: Check the address matches intended by a wildcard expression before evaluating ACL rule order.
  • Common TCP and UDP ports: Look up a service's customary protocol and port, then verify the actual application flow rather than assuming it uses the default.

Sources

Documentation reviewed: 8 October 2026