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.

Rule order is policy. A broad deny near the top can shadow later permits.

Standard versus extended ACLs

ACL type What it matches Typical use
StandardSource IPv4 address onlySimple source filtering
ExtendedProtocol, source, destination, portsApplication-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.

ACL behavior is not identical across IOS, IOS XE, NX-OS, and ASA. Validate syntax and feature support on your target platform.

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
  1. Verify ACL entries and hit counters.
  2. Confirm interface attachment and direction.
  3. Review for unreachable or shadowed lines.
  4. 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.
Build and review an ACL with the Cisco ACL Builder

Use Cisco ACL Builder, then continue with IPv6 Addressing and Subnetting Explained.