Courseiva
SecurityPrivileged EXEC

show access-lists

Verify ACL entries are correct and use hit counts to determine which rules are matching traffic during troubleshooting.

Definition: show access-lists is a Cisco IOS privileged exec command. Displays all configured ACLs or a specific ACL showing each entry with its sequence number, match criteria (permit/deny, protocol, source, destination, ports), and hit count showing how many packets have matched each entry.

Overview

The 'show access-lists' command is a fundamental diagnostic tool in Cisco IOS that displays all configured access control lists (ACLs) on a device, including their individual entries and match counters. ACLs are used to filter traffic based on source/destination IP addresses, protocols, and port numbers, serving as the cornerstone of network security and traffic management. This command is essential for verifying that ACLs are correctly applied, understanding which entries are being hit, and troubleshooting traffic flow issues.

Unlike 'show ip interface' which shows ACL application direction, 'show access-lists' reveals the internal structure and hit counts of each ACL, making it invaluable for validating policy effectiveness. Network engineers reach for this command when investigating why certain traffic is permitted or denied, after making ACL changes, or during routine audits. It fits into the broader workflow of configuration verification: after applying an ACL with 'ip access-group', you use 'show access-lists' to confirm the entries and monitor counters over time.

Important IOS behaviors include that output is buffered and may be truncated if the ACL is very long; you can use 'show access-lists | begin <acl-name>' to filter. The command requires privileged EXEC mode (enable). It does not affect the running configuration but reads from it.

Understanding this command is critical for CCNA and CCNP candidates as ACLs appear in routing, security, and QoS contexts.

Syntax·Privileged EXEC
show access-lists [acl-name | acl-number]

When to Use This Command

  • Verify an ACL is configured correctly before applying it to an interface
  • Use hit counts to confirm traffic is matching the intended ACL entry
  • Diagnose a connectivity issue — find which ACL entry is denying traffic
  • Audit security policies by reviewing all ACL rules

Parameters

ParameterSyntaxDescription
access-list-number-or-name<1-99> | <100-199> | <1300-1999> | <2000-2699> | WORDSpecifies a particular ACL by number or name. Standard ACLs use 1-99 or 1300-1999, extended ACLs use 100-199 or 2000-2699. Named ACLs use a word. If omitted, all ACLs are displayed. Common mistake: using a number outside the valid range or misspelling the name.

Command Examples

Extended ACL with hit counts

Router# show access-lists
Extended IP access list WAN_FILTER
    10 permit tcp 192.168.1.0 0.0.0.255 any eq 443 (1234 matches)
    20 permit tcp 192.168.1.0 0.0.0.255 any eq 80 (567 matches)
    30 deny ip any any log (12 matches)

Understanding the Output

Sequence numbers (10, 20, 30) show entry order — lower numbers are checked first. Hit counts in parentheses show total packet matches since counters were last cleared or device reloaded. An ACL entry with 0 matches that should be matched indicates a problem (traffic not reaching the ACL or matching an earlier entry).

The implicit deny at the end does not appear in show access-lists but is always there.

Configuration Scenarios

Verifying a Standard ACL on a Branch Router

A branch router (R1) has a standard ACL applied to its WAN interface to permit only the management station (10.0.1.100) to access the router via SSH. The engineer needs to confirm the ACL is correctly configured and see hit counts.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2 Management station: 10.0.1.100

Steps

  1. 1.Step 1: Enter privileged EXEC mode: R1> enable
  2. 2.Step 2: Display all ACLs: R1# show access-lists
  3. 3.Step 3: Observe the output for ACL named 'MGMT_ACL' and check hit counts.
Configuration
! ACL configuration on R1
ip access-list standard MGMT_ACL
 permit host 10.0.1.100
 deny any
!
interface GigabitEthernet0/0
 ip access-group MGMT_ACL in

Verify: R1# show access-lists MGMT_ACL Standard IP access list MGMT_ACL 10 permit host 10.0.1.100 (5 matches) 20 deny any (10 matches)

Watch out: Forgetting to apply the ACL to an interface with 'ip access-group' will result in zero matches even if the ACL is configured.

Troubleshooting an Extended ACL Blocking Web Traffic

An extended ACL is applied to block HTTP traffic from the 192.168.1.0/24 network to a web server at 10.0.2.10. Users report they cannot access the server. The engineer uses 'show access-lists' to see if the deny entry is being hit.

Topology

Users (192.168.1.0/24)---R1(Gi0/0)---10.0.12.0/30---(Gi0/1)R2---10.0.2.0/24---Web Server (10.0.2.10)

Steps

  1. 1.Step 1: Enter privileged EXEC mode: R1> enable
  2. 2.Step 2: Display the specific ACL: R1# show access-lists BLOCK_HTTP
  3. 3.Step 3: Check the match count on the deny entry. If matches are increasing, the ACL is blocking traffic as intended.
Configuration
! ACL configuration on R1
ip access-list extended BLOCK_HTTP
 deny tcp 192.168.1.0 0.0.0.255 host 10.0.2.10 eq 80
 permit ip any any
!
interface GigabitEthernet0/0
 ip access-group BLOCK_HTTP in

Verify: R1# show access-lists BLOCK_HTTP Extended IP access list BLOCK_HTTP 10 deny tcp 192.168.1.0 0.0.0.255 host 10.0.2.10 eq www (15 matches) 20 permit ip any any (100 matches)

Watch out: If the permit entry has many matches but the deny has zero, the ACL might not be applied in the correct direction or the traffic might be sourced from a different subnet.

Troubleshooting with This Command

When troubleshooting traffic filtering issues, 'show access-lists' is the first command to run after verifying interface ACL application with 'show ip interface'. Healthy output shows increasing match counters on entries that should be matching traffic. Problem indicators include: zero matches on an entry that should be hit (suggests ACL not applied, wrong direction, or traffic not matching criteria), unexpected matches on deny entries (indicates legitimate traffic being blocked), or counters that never increment (ACL may be misconfigured or not applied).

Focus on the 'matches' field; a high number on a permit entry confirms traffic is passing, while a high number on a deny entry confirms blocking. Common symptoms: users cannot access a resource – check if a deny entry is matching; unexpected access – check if a permit entry is too broad. Step-by-step diagnostic flow: 1) Identify the ACL name/number from the interface configuration. 2) Run 'show access-lists <acl-name>' to see hit counts. 3) If matches are zero, verify ACL application direction and interface. 4) If matches are high on deny, confirm the ACL is correct. 5) Correlate with 'show ip interface' to see which ACL is applied inbound/outbound.

Also use 'debug ip packet' with caution to see actual packet processing, but 'show access-lists' provides a safe, non-intrusive view. For time-based ACLs, check if the time range is active with 'show time-range'. Remember that ACL counters reset on device reload or when the ACL is edited; they are not persistent.

In complex scenarios, compare counters before and after generating test traffic to isolate issues.

CCNA Exam Tips

1.

CCNA exam: ACLs process entries top-down — first match wins

2.

The implicit deny any at the end blocks everything not explicitly permitted

3.

Standard ACLs match source IP only

4.

Extended ACLs match source, destination, protocol, and port

5.

Standard ACL placement: close to destination

6.

Extended ACL placement: close to source (to drop traffic early)

Common Mistakes

Forgetting the implicit deny any at the end — always include an explicit permit for return traffic

Not using hit counts to verify which entries are matching

Applying an ACL in the wrong direction (in vs out) on an interface

Standard ACLs placed close to source — they accidentally block traffic intended for other destinations

show access-lists vs show interfaces

Both 'show access-lists' and 'show interfaces' are essential troubleshooting commands in Cisco IOS, but they address different network layers. While 'show access-lists' reveals filtering criteria and packet matches, 'show interfaces' provides link-level operational status and error counts. They are often discussed together because a connectivity problem may be either an ACL blocking traffic or a physical interface issue.

Aspectshow access-listsshow interfaces
ScopeACL entries (permit/deny, protocol, source/dest, ports, hit counts)Interface states (line protocol, hardware, MAC, MTU, bandwidth, duplex, speed, errors)
Output DetailPer-entry sequence number, match criteria, packet countPer-interface counters: input/output packets, errors, drops, queue statistics
Configuration DependenceShows only ACLs that are explicitly configuredShows all interfaces regardless of configuration (even shutdown)
Impact on TrafficRead-only; no traffic impactRead-only; may cause brief CPU spike if clearing counters (not shown here)
Typical UseVerify ACL logic and hit counts to detect allowed/blocked trafficCheck if interface is up, operational errors, or bandwidth utilization

Use show access-lists when you need to verify which ACL entries are matching traffic and confirm that security policies are being applied as intended.

Use show interfaces when you need to diagnose physical connectivity issues, check interface status and error counters, or monitor link utilization.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches), the command syntax and output are identical to classic IOS. However, on newer IOS-XE versions (16.x+), ACL counters may be displayed in a slightly different format, but the fields remain the same. On NX-OS (Nexus switches), the equivalent command is 'show ip access-lists' or 'show ipv6 access-lists' for IPv6.

NX-OS also supports 'show access-lists' but it may show only IPv4 ACLs; use 'show running-config | section ip access-list' for configuration. On ASA firewalls, the command is 'show access-list' (singular) and output includes hit counts and more details like 'hitcnt'. ASA also uses 'show access-list <name>' to filter.

In IOS-XR, the command is 'show access-lists' but the output is different; it uses a hierarchical structure and requires 'show access-lists ipv4 <acl-name>' for IPv4. For IOS versions 12.x vs 15.x vs 16.x, the output is largely consistent, but 15.x introduced support for object-group ACLs which may show additional lines. Always check the specific platform documentation for nuances like counter persistence and ACL editing behavior.

Related Commands

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions