Access Control Lists (ACLs) are essential for filtering traffic in Cisco networks. For CCNA students, understanding statistics helps verify if rules are working as intended. CCNP candidates should note how stats aid in troubleshooting complex setups like multi-interface ACLs.
After an ACL has been configured and applied to an interface, it can block or permit traffic based on the defined rules. You can check the ACL statistics using the show access-lists command. This command displays ACL statistics for each statement that has been matched.
ACL statistics provide insights into how traffic interacts with your filters. Matches increment each time a packet hits a specific rule, allowing you to confirm permits and denials. This is crucial for debugging: low permit matches might indicate misconfiguration, while high deny matches could reveal unauthorized access attempts.
Applying ACLs to Interfaces
ACLs must be applied using ip access-group <number> in/out on interfaces. Example:
R3# show access-lists
Standard IP access list 1
10 permit host 192.168.10.10 (4 match(es))
20 deny any (8 match(es))
R3#
Examine that some match has been found. So when traffic is matched to ACL and ACL take action on that traffic. The ACL will display the match state here. The matches shown at the output of the show access-lists command increased when traffic increased.
For example, the above ACL is configured for network 192.168.30.0/24. If someone other than PC1 sends a ping to this network. The ACL will drop the packets and the match to deny state will increase. If host 192.168.10.10 sends a ping to this network the state to permit statement will increased. The figure below illustrates some configured ACL statistics.
R3#show access-lists Standard IP access list 1 10 permit host 192.168.10.10 (16 match(es)) 20 deny any (12 match(es))
Notice that matches are recorded. When traffic hits an ACL rule, the router applies the action (permit/deny) and increments the match count displayed in show access-lists.
The matches shown in the output of the show access-lists command increase as traffic increases.
For example, the above ACL is configured for network 192.168.30.0/24. Assuming the ACL is applied inbound on the interface to 192.168.30.0/24 and PC1 is 192.168.10.10, if another host pings, the deny match increases. If host 192.168.10.10 sends a ping to this network, the permit match will increase.
Here’s a breakdown of the command output in a table for clarity:
| Statement | Action | Matches | Explanation |
|---|---|---|---|
| 10 permit host 192.168.10.10 | Allow specific host | 4 | Increments on successful pings from this IP. |
| 20 deny any | Block all else | 8 | Catches unauthorized traffic; useful for debugging. |
Examining ACL Configurations
Now examine the following configuration of ACLs:
R1(config)#access-list 2 permit 192.168.11.10 R1(config)#access-list 2 deny 192.168.11.0 0.0.0.255
Both the permit and deny statements will track information for matches but, the ACL has an implied deny any as the last statement. This statement will not appear in the show access-lists command, therefore, statistics for that statement will not appear.
To view statistics for the implied deny any statement, the statement can be configured manually and will appear in the output. If deny any statement is not configured as the last statement in the ACL, it could cause unexpected results.
Clearing ACL Counters
We can clear the ACL statement counters using the clear access-list counters command. We can use this command alone or with the number or name of a specific ACL. Here’s the output after clearing counters for ACL 1:
R3#clear access-list counters 1 R3#show access-lists Standard IP access list 1 10 permit host 192.168.10.10 (0 match(es)) 20 deny any (0 match(es))
Best Practices for ACL Statistics
- Always add explicit
deny any loglast to track hidden denials. - Monitor with
show loggingfor denied traffic. - Use named ACLs for better management:
ip access-list standard MYACL.
Troubleshooting Tips
If matches don’t increment: Check interface application, traffic direction, and ACL order. For example, in troubleshooting ACL blocks with match counts on router, verify the ACL is applied correctly and test with tools like ping or traceroute.
FAQs
What does the show access-lists command reveal about ACLs?
The show access-lists command displays configured ACLs and their match counts for each statement, showing how many times traffic has hit permit or deny rules. This helps verify filtering effectiveness, with matches increasing as traffic flows through the interface. For example, in ACL 1, a permit host might show 4 matches from allowed pings, while deny any shows 8 from blocks.
How can I track statistics for the implied deny any in an ACL?
The implied deny any doesn’t appear in show access-lists output by default, so no stats are visible. To track it, manually add deny any as the last explicit statement in your ACL configuration. This makes it show up with match counts, preventing unexpected results from order issues and aiding troubleshooting
What is the clear access-list counters command used for?
This command resets match counters for ACL statements, either for all ACLs or a specific one (e.g., clear access-list counters 1). After running it, show access-lists will display 0 matches, allowing fresh monitoring of traffic. It’s essential for testing configurations without old data interference, as seen in examples where counters reset to zero for permit and deny lines.
Why should I use explicit deny any log in ACLs?
Adding explicit deny any log as the last statement tracks hidden denials with match counts and logs details via show logging. This best practice enhances visibility for unauthorized traffic, prevents order-related blocks, and supports advanced troubleshooting. In extended ACLs, it pairs with port-specific rules for granular control in enterprise networks.
How do ACL match counts help in troubleshooting?
Match counts in show access-lists indicate if rules are working: low permits might mean misapplied interfaces or wrong directions, while high denials signal blocks. Test with pings to increment counters, check order (top-down processing), and use tables for breakdowns.
