Troubleshooting Access Control Lists (ACLs) in CCNA
ACL troubleshooting focuses on finding conflicting permit/deny statements, verifying correct inbound/outbound application on interfaces, and accounting for the implicit deny at the end of every list.
The Implicit Deny Problem
Every ACL ends with an invisible `deny ip any any` (or `deny any` for standard ACLs). A common mistake is configuring an ACL with only deny statements. In this scenario, all traffic will be dropped. To fix this, you must add an explicit `permit ip any any` at the end of the ACL to allow unlisted traffic to flow.
Rule Order Matters
ACLs process rules top-down, stopping at the first match. If you place a broad rule (like `permit ip any any`) above a specific deny rule (like `deny host 192.168.1.5`), the specific deny will never be hit. Always sequence ACLs from most specific to least specific. Use `show access-lists` to view the sequence numbers and match counters.
Inbound vs. Outbound Application
An ACL does nothing until applied to an interface using `ip access-group [number/name] [in | out]`. Applying an ACL in the wrong direction is a frequent error. 'Inbound' filters traffic entering the router interface, while 'Outbound' filters traffic leaving the interface. Verify application using `show ip interface`.
❓ Frequently Asked Questions
What happens if an ACL has no permit statements?
Because of the implicit deny at the end, the ACL will drop all traffic passing through the interface it is applied to.
How can you tell if an ACL rule is actively blocking traffic?
Use 'show access-lists'. The output displays match counters for each line, indicating how many packets hit that specific rule.
Where should extended ACLs be placed?
Extended ACLs should be placed as close to the source of the traffic as possible to prevent routing unnecessary packets.