Understanding Cisco ACLs: Syntax and Examples

Cisco ACL syntax is easy to read once you know the pattern, but one small mistake can block the wrong subnet or expose traffic you meant to control. If you need clean policy enforcement without creating outages, the difference is in how you write the rule, where you apply it, and what the device matches first.

Primary Topic	Cisco ACL syntax as of July 2026
ACL Types	Standard and extended ACLs as of July 2026
Match Criteria	Source IP, destination IP, protocol, and ports as of July 2026
Wildcard Mask Use	Inverse matching for hosts, subnets, and ranges as of July 2026
Default Behavior	Implicit deny at the end of every ACL as of July 2026
Common Placement Rule	Standard near destination, extended near source as of July 2026
Best For	Traffic filtering, management access control, NAT matching, and policy enforcement as of July 2026

Readers often search for Cisco ACL syntax because the concept sounds simple until the first outage. A rule that looks correct on paper can fail because of a wildcard mask, the wrong interface direction, or a deny that shadows every later permit.

This guide gives you the practical version: what ACLs do, how Cisco ACL format works, why standard and extended ACLs behave differently, where to place them, and how to verify them before they become a problem. The examples also map cleanly to the kind of skills covered in the Cisco CCNA v1.1 (200-301) course, where ACLs show up in routing, segmentation, and basic security control.

What Are Cisco ACLs and Why Do They Matter?

ACLs are one of the simplest control mechanisms on a Cisco device, but they do a lot of heavy lifting. They let you permit or deny traffic based on a rule set that is evaluated in order, which makes them useful for both security and day-to-day network policy.

At the network layer, ACLs can filter traffic by source IP, destination IP, protocol type, and port number. That means you can stop a user subnet from reaching a sensitive server, protect a management interface, or allow only DNS and HTTPS while dropping everything else.

Why ACLs still matter in real environments

ACLs are valued because they are fast, local, and auditable. The logic lives directly on the Cisco router or switch, which means the device can enforce policy without sending traffic to another appliance first.

• Simplicity: ACLs are concise and easy to apply once the match criteria are clear.
• Performance: Cisco devices process ACLs efficiently for basic packet filtering.
• Auditability: A named ACL can be documented, reviewed, and tested as policy.
• Segmentation: ACLs help enforce separation between VLANs, user groups, and application zones.

That last point matters when you are working with Cisco VLANs separate broadcast domains inter-VLAN routing ACL documentation in a lab or production network. VLANs isolate Layer 2 broadcast traffic, but they do not automatically prevent one VLAN from talking to another. ACLs are often what turns simple segmentation into a real access policy.

Policy without placement is just intent. A Cisco ACL only works the way you expect when the rule order, wildcard mask, and interface direction all line up with the traffic path.

For Cisco guidance on ACL behavior, the best starting point is the official documentation at Cisco. For broader security control design, the NIST Cybersecurity Framework is useful because it frames access control as part of a larger risk reduction strategy rather than a one-off config task.

How Does Cisco ACL Syntax Work?

Cisco ACL syntax works by matching traffic line by line until the device finds the first rule that fits. That first match decides whether the packet is permitted or denied, and everything after that is ignored for that packet.

1. Start with an action: Each rule begins with permit or deny.
2. Specify the match: The ACL then checks source, destination, protocol, or ports depending on the ACL type.
3. Apply a wildcard mask: The wildcard tells Cisco which bits must match and which bits may vary.
4. Evaluate top to bottom: The first matching line wins.
5. End with implicit deny: Anything not explicitly permitted is denied by default.

This order matters more than almost anything else in ACL design. A broad deny near the top can override every later permit, while a precise permit placed too late may never be reached.

Named versus numbered ACLs

Cisco supports both numbered and named ACLs, and the syntax choice affects readability and maintenance. Numbered ACLs are compact, but named ACLs are easier to understand when the policy grows beyond a few lines.

• Numbered ACLs: Short, familiar, and common in smaller configs.
• Named ACLs: Easier to document, revise, and troubleshoot.
• Extended named ACLs: Best when the rule set needs clear labels for future change control.

In practice, Cisco ACL commands are easier to troubleshoot when the syntax mirrors the traffic path. That is one reason ACL writing is a core networking skill in the Cisco CCNA v1.1 (200-301) curriculum: it teaches you to think in terms of packets, interfaces, and policy, not just commands.

For current command references, Cisco’s official docs and Cisco Learning Network are the safest places to verify platform-specific behavior and syntax details.

What Is the Difference Between Standard and Extended ACLs?

Standard ACLs match source IP address only, while extended ACLs can match source, destination, protocol, and port. That one difference changes how precise the rule can be, and it determines where the ACL should usually be placed.

Standard ACL	Best for simple source-based decisions, such as allowing or blocking a management host or subnet.
Extended ACL	Best for traffic control by service, such as allowing HTTP and HTTPS while denying Telnet or unwanted application traffic.

When a standard ACL is the right fit

A standard ACL is useful when the only question is where traffic came from. For example, you might block a guest subnet from accessing a router’s management line or permit only a trusted admin subnet.

Because standard ACLs are broader, they should be used carefully. If you place them too close to the source, they may block too much traffic because they cannot distinguish between different applications coming from the same network.

When an extended ACL is the better choice

An extended ACL is the better option when you need to control what kind of traffic is allowed. You can allow DNS, block Telnet, permit web access, or limit one server from talking to another on a specific port.

That makes extended ACLs the better tool for security-focused filtering. They let you express policy more precisely, which reduces the chance of collateral damage from overly broad rules.

For context on service-level access control, Cisco’s official documentation remains the best source for platform behavior, while the CIS Controls offer a useful policy lens for deciding which traffic should be allowed at all.

How Do Wildcard Masks Work in Cisco ACL Syntax?

Wildcard masks are the inverse of subnet masks. In Cisco ACL syntax, a 0 bit means “must match exactly,” and a 1 bit means “ignore this position.”

This is the part that trips up many beginners. A subnet mask says what belongs to the network, but a wildcard mask says what the ACL should match.

Common wildcard examples

• Single host: host 192.168.1.10 is shorthand for 192.168.1.10 0.0.0.0.
• Whole /24 subnet: 192.168.1.0 0.0.0.255 matches all addresses from 192.168.1.0 to 192.168.1.255.
• Two adjacent /25s: 192.168.1.0 0.0.0.127 matches the lower half of a /24.

A good mental model is to read the wildcard from left to right and ask: “Which octets must be identical, and which can vary?” That is especially useful when you are dealing with Cisco ACL network wildcard mask aggregation same octet patterns, where two ranges sit in the same third octet and the wildcard has to reflect that precisely.

One quick check is to convert the subnet mask to wildcard form by subtracting each octet from 255. For example, 255.255.255.0 becomes 0.0.0.255. If the mask you wrote does not match that logic, stop and verify before pushing the change.

For deeper technical background on packet matching and address handling, IETF standards and Cisco documentation provide the most reliable references.

Where Should You Place an ACL and Which Direction Should It Face?

ACL placement determines which traffic the device actually sees, and direction determines whether the ACL evaluates packets entering or leaving an interface. A correct rule in the wrong direction behaves like the wrong rule.

The common rule of thumb is straightforward: place standard ACLs close to the destination and extended ACLs close to the source. That reduces unnecessary traffic flow and avoids filtering too broadly when you do not have enough match detail.

Inbound versus outbound

An inbound ACL filters traffic as it enters an interface. An outbound ACL filters traffic as it leaves the interface after routing decisions have been made.

• Inbound: Good for stopping unwanted traffic early.
• Outbound: Useful when several sources feed one exit point and you want a single policy gate.
• Placement on routed interfaces: Determines which side of the network path the ACL sees first.

Practical placement examples

If you want to protect a server VLAN from a user VLAN, an extended ACL near the user side usually makes more sense. If you want to restrict who can reach a router console or VTY line, a standard ACL near the destination management interface is often cleaner.

Placement also matters for inter-VLAN routing ACL documentation. A VLAN may separate broadcast domains, but ACLs enforce which devices can talk across those domains once routing is enabled.

The operational side of placement is part of change discipline too. Change Management matters because ACLs affect live traffic immediately, and bad placement can produce outages faster than almost any other small config change.

What Are Common Cisco ACL Syntax Examples?

Cisco ACL commands are easier to understand when you see them applied to real use cases. The examples below show the difference between source-based filtering, service-based filtering, and the effect of the implicit deny.

Example of a standard ACL

access-list 10 permit 192.168.10.0 0.0.0.255
access-list 10 deny any

This standard ACL permits the 192.168.10.0/24 subnet and denies everything else. Because standard ACLs only inspect the source, this is appropriate for a simple trust-based policy, such as allowing one admin subnet to reach a management interface.

Example of an extended ACL

ip access-list extended WEB-FILTER
 permit tcp 10.10.10.0 0.0.0.255 any eq 80
 permit tcp 10.10.10.0 0.0.0.255 any eq 443
 deny tcp 10.10.10.0 0.0.0.255 any eq 23
 permit ip any any

This extended ACL allows HTTP and HTTPS, blocks Telnet, and then permits everything else. The final line is important because without it, the implicit deny would block any traffic that was not matched earlier.

Example of a host permit

access-list 15 permit host 172.16.1.25

This syntax is clean when you want to match a single host without writing a wildcard mask. It is one of the simplest ways to create a precise source-based exception.

Here is the real lesson: ACLs are not just block lists. They are policy statements, and policy is only as good as the order you wrote it in. If you need to test a rule path before production, lab it first and compare the result to the configuration line by line.

For Cisco-specific syntax validation, the official Cisco documentation is still the most authoritative reference. For broader packet filtering concepts, Cloudflare’s ACL overview is useful, but Cisco behavior should always be checked against Cisco first.

How Do ACLs Support NAT, Security, and Policy Enforcement?

ACLs are used for more than filtering traffic. On Cisco devices, they can also define which internal addresses are translated by NAT, which hosts may reach protected systems, and which services should be allowed across zones.

In NAT configurations, an ACL often identifies the inside source addresses eligible for translation. That makes the ACL part of address selection rather than just a security rule. If the ACL is wrong, NAT may translate the wrong traffic or no traffic at all.

Security use cases

• User-to-server restriction: Limit which subnets can reach a database network.
• Management access control: Permit SSH only from an admin subnet.
• Service limitation: Block Telnet and legacy protocols while allowing secure alternatives.
• Segment control: Reduce east-west traffic between VLANs and routed interfaces.

From a policy standpoint, ACLs are a simple way to enforce “who can talk to what” without adding complexity. They can also support compliance-oriented network design under frameworks like NIST CSF, where access control and segmentation are core protective functions.

That is why ACLs are often treated as foundational rather than advanced. They do not replace firewalls, but they do give you direct control at the device edge and inside routed networks. If your goal is to reduce unnecessary exposure quickly, ACLs are one of the first tools to get right.

How Do You Test and Troubleshoot Cisco ACL Syntax?

ACL troubleshooting starts with one question: did the device match the rule you thought it would match? If the answer is no, the issue is usually order, wildcard, direction, or interface placement.

1. Confirm intent: Write down the source, destination, protocol, and port you want to affect.
2. Inspect syntax: Check permit or deny, wildcard mask, and the ACL type.
3. Verify placement: Make sure the ACL is applied to the correct interface and direction.
4. Generate test traffic: Use a ping, SSH attempt, web request, or application test.
5. Review counters: Confirm whether the expected line is incrementing.

Common mistakes

• Wrong wildcard mask: The ACL matches too much or too little.
• Wrong rule order: A broad deny shadows a later permit.
• Wrong interface: The ACL is applied where the traffic does not flow.
• Wrong direction: Inbound and outbound behavior are reversed.
• Forgotten implicit deny: Traffic not explicitly allowed is dropped.

Logging can help confirm matches, but it should be used carefully. Excessive logging can clutter the device and make troubleshooting harder, especially on busy links. Use it to validate the rule, then remove or reduce it if the ACL is stable.

For operational observability, Cisco documentation is the right reference for commands such as ACL inspection and interface verification. If you are troubleshooting more broadly across routing and forwarding, the packet-level model is helpful because ACLs act on traffic decisions made at the packet level.

What Are the Best Practices for Writing Better ACLs?

Good ACL design is about precision, readability, and review. The best ACLs are not the shortest ones; they are the ones that another engineer can understand quickly during a change window or incident.

Start by writing the narrowest rules first. Specific permits should appear before broad denies, or you risk blocking traffic you meant to allow. The goal is to make the configuration reflect the business rule exactly, not approximately.

Practical ACL habits

• Name ACLs clearly: Use a name that explains the purpose, not just the function.
• Document intent: Record why the ACL exists and what traffic it affects.
• Keep rule order intentional: Match specific traffic before broad statements.
• Test in a lab: Validate syntax and behavior before production deployment.
• Review stale entries: Remove exceptions that are no longer needed.

If you are comparing your lab output to vendor guidance, use Cisco’s official docs and your own verification commands rather than guessing from a generic example. That habit saves time, especially when ACLs interact with NAT, routed VLANs, or management access rules.

For workforce context, the U.S. Bureau of Labor Statistics Occupational Outlook Handbook continues to show strong demand for networking and security-related roles, which is why practical ACL skills remain relevant in real operations. ACLs are not theoretical trivia; they are a routine part of keeping networks controlled and supportable.

What Is the Best Way to Learn Cisco ACL Syntax?

The best way to learn Cisco ACL syntax is to write rules, test them, and break them in a lab before you touch production. Reading syntax alone rarely builds the intuition needed to avoid mistakes under pressure.

Official vendor documentation should be your baseline. Cisco’s product and configuration guides explain how ACLs behave on specific platforms, and Cisco Learning Network is useful for reinforcement and exam-aligned practice. The difference between reading and doing becomes obvious the first time an ACL blocks an SSH session you expected to keep open.

A practical learning sequence

1. Memorize the basic format: Permit or deny, match criteria, wildcard mask, optional protocol or port.
2. Practice wildcard masks: Convert host and subnet examples until they are automatic.
3. Build standard ACLs first: Learn simple source filtering before moving to extended ACLs.
4. Move to extended ACLs: Add protocol and port matching for realistic service control.
5. Verify with traffic tests: Check counters and confirm the intended result.

That sequence is also why ACL work fits naturally into the Cisco CCNA v1.1 (200-301) learning path. The syntax becomes much easier once you see how traffic actually moves through routed interfaces and VLANs.

For additional policy context, NIST helps connect ACL design to broader access control goals, while Cisco’s own documentation keeps the implementation grounded in how the device really behaves.

When Should You Use ACLs, and When Should You Not?

Use ACLs when you need fast, direct traffic control on a Cisco device. Do not rely on ACLs alone when you need deep inspection, user identity awareness, or application-layer decisions that packet filtering cannot provide.

Use ACLs when you need to

• Block or permit traffic between subnets.
• Restrict access to management services.
• Support NAT source matching.
• Limit unwanted protocols between network segments.
• Enforce a simple, device-local access policy.

Do not use ACLs as the only control when

• You need advanced inspection of application content.
• Policy depends on user identity instead of IP address.
• The environment requires central orchestration across many devices.
• You need full threat prevention rather than basic traffic control.

That boundary is important. ACLs are excellent for deterministic packet decisions, but they are not a substitute for a firewall policy engine or broader security architecture. They work best when used as one part of a layered network design.

An ACL is strongest when its job is narrow. The more precise the rule, the easier it is to audit, troubleshoot, and keep in sync with business intent.

For governance and control design, pairing ACL thinking with NIST CSF or the Center for Internet Security helps keep the configuration aligned to security outcomes instead of just command syntax.

Conclusion

Cisco ACL syntax becomes straightforward once you understand four things: the rule order, the wildcard mask, the ACL type, and the interface direction. Those are the details that decide whether your policy works cleanly or causes a problem.

Standard ACLs are useful when source IP is enough. Extended ACLs are the better choice when you need granular control over protocols and ports. In both cases, the safest approach is the same: write the rule clearly, place it correctly, test it, and verify the counters before you call the job done.

If you are building hands-on networking skills, this is a topic worth practicing repeatedly. ACLs show up in routing labs, VLAN segmentation, NAT, and basic security enforcement, and they are one of the fastest ways to improve traffic control without adding unnecessary complexity.

Use Cisco’s official documentation, validate your syntax in a lab, and compare your results against real traffic. That is how ACL knowledge turns into reliable configuration skill.

CompTIA®, Cisco®, Microsoft®, AWS®, EC-Council®, ISC2®, ISACA®, and PMI® are trademarks of their respective owners.