What an ACL is
An ACL is an ordered list of conditions that permit or deny matching traffic. Cisco ACL processing is top-down. The first matching line is applied, and unmatched traffic hits an implicit deny.
Standard versus extended ACLs
| ACL type | What it matches | Typical use |
|---|---|---|
| Standard | Source IPv4 address only | Simple source filtering |
| Extended | Protocol, source, destination, ports | Application-aware traffic policy |
Standard ACLs are simpler, but extended ACLs provide precise control for TCP/UDP services and destination-specific policy.
Named versus numbered ACLs
Both styles are valid. Named ACLs are usually easier to read and maintain in larger policies.
Named ACL example
ip access-list extended WEB-SERVERS
remark Permit HTTPS from user subnet
permit tcp 10.10.10.0 0.0.0.255 host 172.16.10.20 eq 443
deny ip any any log
How wildcard masks work
Wildcard masks are inverse masks:
- Bit value 0 means "must match this bit".
- Bit value 1 means "ignore this bit".
Example: subnet mask 255.255.255.0 corresponds to wildcard 0.0.0.255.
Syntax reminders
- host 172.16.10.20 matches one address.
- any matches all addresses.
- 10.10.10.0 0.0.0.255 matches an entire /24.
Inbound versus outbound placement
Inbound ACLs filter traffic as it enters an interface. Outbound ACLs filter traffic before it leaves an interface. Placement depends on topology, policy intent, and operational model.
Configuration examples and ordering
Extended ACL with remark and logging
ip access-list extended WEB-SERVERS
remark Permit HTTPS from user subnet
permit tcp 10.10.10.0 0.0.0.255 host 172.16.10.20 eq 443
deny ip any any log
!
interface GigabitEthernet1/0/1
ip access-group WEB-SERVERS in
Put specific permits above broad denies. Check for shadowed entries after edits.
Verification commands
Cisco verification sequence
show access-lists
show ip interface
show running-config | section access-list
- Verify ACL entries and hit counters.
- Confirm interface attachment and direction.
- Review for unreachable or shadowed lines.
- Confirm logging impact in production environments.
Common mistakes
- Forgetting implicit deny when no final permit exists.
- Using incorrect wildcard masks for intended ranges.
- Placing broad denies above required permits.
- Applying ACL in the wrong direction on an interface.
- Skipping remarks, making policy intent unclear in reviews.
FAQ
Do ACLs always process all lines?
No. Processing stops at the first match.
Should I always use named ACLs?
Named ACLs are often clearer, but numbered ACLs may be required by existing standards.
Does adding log to every deny always make sense?
Not always. Logging can be useful but may add overhead; tune based on platform capacity and operational goals.
Key takeaways
What to remember
- ACLs are first-match and top-down, with implicit deny at the end.
- Wildcard masks are inverse matching logic, not subnet masks.
- Placement, ordering, and verification are equally important.
Use Cisco ACL Builder, then continue with IPv6 Addressing and Subnetting Explained.