show ip access-lists
Displays the contents of all current IP access lists or a specific access list, including the number of matches for each entry, used to verify and troubleshoot ACL configuration and traffic filtering.
Definition: show ip access-lists is a Cisco IOS privileged exec command. Displays the contents of all current IP access lists or a specific access list, including the number of matches for each entry, used to verify and troubleshoot ACL configuration and traffic filtering.
Overview
The `show ip access-lists` command is a fundamental diagnostic tool in Cisco IOS that displays the contents of all configured IP access control lists (ACLs) or a specific ACL, along with the packet match counts for each entry. This command is essential for verifying ACL configuration, troubleshooting traffic filtering issues, and understanding which rules are being hit in production networks. ACLs are a cornerstone of network security and policy enforcement, used to permit or deny traffic based on source/destination IP addresses, protocols, and port numbers.
The command provides real-time visibility into ACL operation, showing the exact number of packets that have matched each line since the ACL was last applied or the counters were cleared. Network engineers reach for this command when they need to confirm that an ACL is correctly filtering traffic as intended, or when troubleshooting connectivity problems that may be caused by an overly restrictive or misconfigured ACL. Unlike `show running-config | include access-list`, which only shows the configuration, `show ip access-lists` adds the critical operational data of match counts, making it indispensable for validation.
It fits into the broader troubleshooting workflow after initial connectivity tests (like ping) fail, helping to isolate whether an ACL is blocking traffic. The command requires privileged EXEC mode (enable) and does not affect the running configuration. Output is buffered and may be truncated if the ACL is very long, so using the `| begin` or `| section` filters can help.
Important IOS behavior: match counters are cumulative from the last clear (via `clear access-list counters`) or router reload; they can be used to identify which ACE is actively being hit. The command also shows the timestamp of the last match for each entry in newer IOS versions, aiding in temporal analysis. Understanding this command is critical for CCNA and CCNP candidates as ACL troubleshooting is a common exam topic and real-world task.
show ip access-listsWhen to Use This Command
- Verify that an ACL is correctly filtering traffic by checking hit counts after applying it to an interface.
- Troubleshoot why certain traffic is being blocked or allowed unexpectedly by examining the order and matches of ACL entries.
- Confirm the sequence numbers and content of a named or numbered ACL before making modifications.
- Audit ACLs for security compliance by reviewing the rules and their match counts.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| access-list-number-or-name | <1-99> | <100-199> | <1300-1999> | <2000-2699> | WORD | Specifies a particular ACL to display. Can be a standard ACL number (1-99, 1300-1999), extended ACL number (100-199, 2000-2699), or a named ACL (WORD). If omitted, all IP ACLs are shown. Common mistake: using a number outside the valid range or misspelling a name. |
Command Examples
View all IP access lists
show ip access-listsExtended IP access list 101
10 permit tcp 192.168.1.0 0.0.0.255 any eq 80 (12 matches)
20 deny tcp any any eq 23 (5 matches)
30 permit ip any any (100 matches)
Extended IP access list BLOCK_SSH
10 deny tcp any 10.0.0.0 0.255.255.255 eq 22 (3 matches)
20 permit ip any any (200 matches)Line 1: Access list type (Extended IP) and identifier (101 or BLOCK_SSH). Each entry: Sequence number (10,20,30), action (permit/deny), protocol, source/destination with wildcard mask, optional port (eq 80), and match count in parentheses. Match count shows how many packets have matched that line since the last clear or reload.
View a specific named access list
show ip access-lists BLOCK_SSHExtended IP access list BLOCK_SSH
10 deny tcp any 10.0.0.0 0.255.255.255 eq 22 (3 matches)
20 permit ip any any (200 matches)Only the specified ACL is displayed. The output shows two entries: the first denies SSH traffic to the 10.0.0.0/8 network (3 matches), and the second permits all other traffic (200 matches).
Understanding the Output
The output lists each configured IP access list (both numbered and named) with its type (Standard or Extended). For each ACL, entries are shown in order with their sequence number, action (permit/deny), protocol (ip, tcp, udp, etc.), source and destination addresses with wildcard masks, and optional port information. The most critical field is the match count in parentheses after each entry, which increments every time a packet matches that line.
A high match count on a deny entry may indicate blocked traffic that should be allowed, while a low or zero match count on a permit entry could mean the ACL is not being applied correctly or the traffic is not reaching the router. The order of entries is important because ACLs are processed top-down; once a match occurs, no further entries are checked. If no matches appear on any entry, the ACL might not be applied to an interface, or the implicit deny at the end is blocking all traffic (which does not show a match count).
Use this command to verify ACL logic and troubleshoot filtering issues.
Configuration Scenarios
Verify ACL blocking traffic from a specific subnet
A network engineer suspects that an extended ACL applied inbound on a router interface is blocking HTTP traffic from the 192.168.1.0/24 subnet to a web server at 10.0.0.1. The goal is to confirm the ACL is configured correctly and that packets are being matched.
Topology
PC(192.168.1.10)---(Gi0/0)R1(Gi0/1)---10.0.0.0/24---WebServer(10.0.0.1)Steps
- 1.Step 1: Enter privileged EXEC mode: enable
- 2.Step 2: Display all ACLs: show ip access-lists
- 3.Step 3: Identify the ACL applied to the inbound direction of Gi0/0 (e.g., ACL 110).
- 4.Step 4: Check the match count for the deny statement that blocks 192.168.1.0/24. If count is increasing, the ACL is blocking traffic.
- 5.Step 5: If no matches, verify ACL application with: show ip interface Gi0/0 | include access list
! Configure ACL 110 to block HTTP from 192.168.1.0/24 to 10.0.0.1 R1(config)# access-list 110 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80 R1(config)# access-list 110 permit ip any any R1(config)# interface GigabitEthernet0/0 R1(config-if)# ip access-group 110 in
Verify: R1# show ip access-lists 110 Extended IP access list 110 10 deny tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq www (5 matches) 20 permit ip any any (100 matches) The '5 matches' indicates the deny line is being hit.
Watch out: Forgetting to add a permit statement after the deny will cause all traffic to be dropped due to implicit deny. Always include a permit any any at the end if the goal is to only block specific traffic.
Troubleshoot ACL sequence order with named ACL
A named ACL 'BLOCK_SSH' is applied outbound on a router interface to prevent SSH access from a management subnet to all other subnets. The engineer notices that SSH connections are still succeeding and needs to verify the ACL order and match counts.
Topology
Mgmt(10.0.0.0/24)---(Gi0/0)R2(Gi0/1)---10.0.1.0/24Steps
- 1.Step 1: Enter privileged EXEC mode: enable
- 2.Step 2: Display the named ACL: show ip access-lists BLOCK_SSH
- 3.Step 3: Examine the sequence numbers and match counts. If the permit statement has matches but the deny does not, the order may be wrong.
- 4.Step 4: Use sequence numbers to reorder if needed: ip access-list extended BLOCK_SSH, then resequence.
- 5.Step 5: Verify the ACL is applied to the correct interface and direction: show ip interface Gi0/0 | include access list
! Configure named ACL BLOCK_SSH R2(config)# ip access-list extended BLOCK_SSH R2(config-ext-nacl)# deny tcp 10.0.0.0 0.0.0.255 any eq 22 R2(config-ext-nacl)# permit ip any any R2(config-ext-nacl)# exit R2(config)# interface GigabitEthernet0/0 R2(config-if)# ip access-group BLOCK_SSH out
Verify: R2# show ip access-lists BLOCK_SSH Extended IP access list BLOCK_SSH 10 deny tcp 10.0.0.0 0.0.0.255 any eq 22 (0 matches) 20 permit ip any any (50 matches) If the deny line shows 0 matches but SSH is still working, the ACL may not be applied correctly or the traffic is not matching the source/destination.
Watch out: Applying the ACL in the wrong direction (inbound vs outbound) is a common mistake. For outbound ACLs, the source is the router's own interface, not the original source. Ensure the ACL is applied to the correct interface and direction based on traffic flow.
Troubleshooting with This Command
When using `show ip access-lists` for troubleshooting, the key is to interpret match counts and sequence order. Healthy output shows match counts incrementing as expected for the intended traffic. For example, if an ACL is meant to block Telnet from a specific subnet, the deny line should show matches when Telnet traffic from that subnet is attempted.
Problem indicators include: (1) zero matches on a line that should be hit, suggesting the ACL may not be applied, the traffic is not matching due to incorrect source/destination/protocol, or the ACL is applied in the wrong direction; (2) matches on a permit line that should be blocked, indicating a missing deny statement or incorrect order; (3) high match counts on an implicit deny (not shown but implied) causing drops, which can be inferred if traffic is failing but no explicit deny has matches. Focus on the sequence numbers: ACLs are processed top-down, so the first match is applied. If a permit line appears before a deny line for the same traffic, the permit will be hit and the deny ignored.
Common symptoms this command helps diagnose include: users unable to access a server (check if ACL on the server's inbound path is blocking), unexpected access (check if permit lines are too broad), and asymmetric routing issues (check ACLs on both directions). A step-by-step diagnostic flow: (1) Identify the ACL applied to the interface in question using `show ip interface`. (2) Display the ACL with `show ip access-lists [name]`. (3) Clear counters with `clear access-list counters` to start fresh. (4) Generate test traffic (e.g., ping, telnet) from the affected source. (5) Re-display the ACL and check which line incremented. If no line increments, the traffic may be dropped by an ACL on another interface or by a different mechanism (e.g., VACL, route-map).
Correlate with `show logging` for ACL log messages if logging is enabled, and with `debug ip packet` (carefully) to see if packets are being dropped. Also, compare with `show access-lists` (which includes all types) and `show ip interface` to confirm application. In summary, `show ip access-lists` is the go-to command for ACL troubleshooting, providing immediate visibility into rule hits and helping pinpoint configuration errors.
CCNA Exam Tips
Remember that the implicit deny at the end of every ACL does not show a match count; if no matches appear, the implicit deny is likely blocking traffic.
The sequence numbers (10,20,30) are used for editing ACLs; the exam may test that you can insert or delete entries using these numbers.
Match counts reset after a reload or after using the 'clear access-list counters' command; be aware of this when troubleshooting.
Named ACLs are displayed with their name; the exam may ask you to differentiate between numbered and named ACLs.
Common Mistakes
Assuming that a zero match count means the ACL is not working; it could mean the traffic is not hitting the router or the ACL is applied to the wrong interface/direction.
Forgetting that ACLs are processed top-down and that a permit entry later in the list will never be reached if a deny entry above it matches.
Misinterpreting the wildcard mask; the output shows the wildcard mask used in the ACL, not the subnet mask.
show ip access-lists vs show access-lists
These two commands are commonly confused because both display ACL configurations, but they differ in scope: show ip access-lists only shows IP ACLs, while show access-lists shows all ACL types including MAC ACLs.
| Aspect | show ip access-lists | show access-lists |
|---|---|---|
| Scope | Shows only IP ACLs (standard, extended, named) | Shows all ACLs (IP, MAC, etc.) |
| Types displayed | IP-only ACLs | All ACL types |
| Hit count | Shows match count per entry | Shows match count per entry |
| Sequence numbers | Shows sequence numbers | Shows sequence numbers |
| Use case | Focus on IP traffic filtering | Comprehensive security review |
Use show ip access-lists when you need to verify or troubleshoot only IP-based ACLs and want to focus on IP traffic filtering.
Use show access-lists when you need to see all ACLs configured on the device, including non-IP like MAC ACLs, for a comprehensive security review.
Platform Notes
In IOS-XE, the command syntax and output are identical to classic IOS, but the output may include additional fields like 'hitcnt' and 'hitcnt32' for 64-bit counters on newer platforms. The command is available in all IOS versions (12.x, 15.x, 16.x) with consistent behavior. In NX-OS, the equivalent command is `show ip access-lists` as well, but the output format differs: it shows the ACL name, sequence numbers, and match counts in a slightly different layout.
NX-OS also supports `show ip access-list summary` for a concise view. For ASA firewalls, the equivalent is `show access-list` (without 'ip'), which displays ACLs with hit counts and optional time-based entries. ASA also uses `show access-list <name>` for specific ACLs.
In IOS-XR, the command is `show access-lists ipv4 <name>` or `show access-lists ipv4` to display all IPv4 ACLs. The output includes sequence numbers and match counts, but the syntax is different (e.g., 'ipv4' keyword). Note that IOS-XR uses a different ACL configuration model (with 'commit' required).
For CCNA/CCNP study, focus on IOS/IOS-XE as the primary platform, but be aware of these differences for real-world multi-platform environments.
Related Commands
show access-lists
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.
show ip interface
Displays the status and configuration of all IP interfaces on a Cisco router, including IP address, protocol status, and interface statistics, used for verifying interface IP configuration and troubleshooting connectivity issues.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions