Security and policy

Cisco ACL Builder

Build standard and extended Cisco IOS IPv4 ACLs with ordered entries, remarks, logging options, and interface application examples.

Calculated locally

Learn ACL logic before deployment

Review wildcard masks, first-match behavior, and verification steps in the full learning article.

Read Cisco ACLs and Wildcard Masks Explained

ACL settings

Select ACL style and identity before adding ACEs.

ACL processing is top-down with an implicit deny at the end.

Access control entries (ACEs)

Add, remove, reorder, and edit rules in the exact order Cisco will process them.

Generated Cisco configuration

Review and copy the full ACL before deployment.

Configure ACL settings and add entries to generate commands.
No warnings yet.

How to use the Cisco ACL Builder

Choose standard or extended ACL mode, define each ACE, then copy the generated IOS syntax.

1

Set ACL identity

Pick named or numbered ACL mode first to enforce the correct Cisco command format.

2

Add ordered ACEs

Build permit and deny entries from top to bottom exactly as the device will evaluate them.

3

Validate before deploy

Review implicit deny, duplicate rules, and shadowing warnings before change windows.

4

Apply to interface

Add an inbound or outbound interface example to document deployment intent.

Standard versus extended ACLs

Standard ACLs match source IPv4 addresses only, while extended ACLs match protocol, source, destination, and ports.

Standard ACLs

Use for simple source-based filtering. Standard ACL entries cannot match destination or TCP/UDP ports.

Extended ACLs

Use for traffic-specific policy where protocol, destination, and service ports matter.

Named versus numbered ACLs

Named ACLs are easier to read, while numbered ACLs are common in legacy environments.

Named ACL format

ip access-list extended WEB-SERVERS
 permit tcp 10.10.10.0 0.0.0.255 host 172.16.10.20 eq 443

Numbered ACL format

access-list 101 permit tcp 10.10.10.0 0.0.0.255 host 172.16.10.20 eq 443

How wildcard masks work

Wildcard masks are inverse masks used by ACL entries. 0 bits must match exactly and 1 bits are flexible.

Example: 10.10.10.0 with wildcard 0.0.0.255 matches the full 10.10.10.0/24 source range.

ACL processing order

Cisco evaluates ACL entries top-down and stops on the first match, then applies an implicit deny at the end.

Place specific permits above broad denies to avoid unreachable policy lines.

Inbound versus outbound ACL placement

Apply ACLs close to the source when practical for efficiency and policy clarity.

Inbound

Filters traffic as soon as it enters an interface, often reducing unnecessary forwarding load.

Outbound

Filters traffic leaving an interface, useful when multiple inbound paths should share one policy.

Common Cisco ACL examples

Use these starting points and tailor to your network standards.

ip access-list extended WEB-SERVERS
 remark Allow users to HTTPS server
 permit tcp 10.10.10.0 0.0.0.255 host 172.16.10.20 eq 443
 deny ip any any log

Common ACL mistakes

Most ACL outages come from ordering errors, over-broad denies, and incorrect wildcards.

Frequently asked questions

Quick answers for practical ACL deployment questions.

Can this tool detect every semantic ACL conflict?

No. It provides practical warnings for common issues such as duplicates and likely shadowing, but complex semantics still need engineer review and lab validation.

Should I use named or numbered ACLs?

Named ACLs are generally easier to understand and maintain, especially in large policy sets.

Why does rule order matter so much?

ACLs are first-match. A broad earlier rule can make later rules unreachable.

Related PacketToolbox resources

Use these tools and guides together during design and troubleshooting.

Copied