VMware ESXi and vSphere Cluster Management

Cisco Standard ACLs: Configuration, Processing, and Placement

Learn how Cisco standard IPv4 ACLs match source addresses, process rules, use wildcard masks, apply to interfaces, and protect a server network.

What a Standard IPv4 ACL Does

An Access Control List (ACL) is an ordered collection of permit and deny rules used to control packet forwarding. Each individual rule is called an Access Control Entry (ACE).

A standard IPv4 ACL evaluates only the packet's source IPv4 address. It can decide whether traffic from a source address is permitted or denied, but it cannot distinguish traffic by destination, protocol, or TCP/UDP port.

For example, a standard ACL can block host 172.16.0.10 from reaching a destination through a router interface. It cannot, by itself, block that host only from a particular web server while allowing it to reach another destination. An extended ACL is more granular because it can match source and destination addresses, protocol types, and TCP or UDP ports.

Standard ACLs are comparatively simple to understand and commonly have lower processing overhead than more detailed filtering rules. Their limitation is that source-only matching may affect every destination reached through the interface where the ACL is applied.

How ACL Entries Are Processed

Router IOS evaluates ACL entries from top to bottom, in sequence. The router compares the packet with the first ACE, then the second, and so on.

1. If the packet matches an ACE, the router immediately performs that ACE's permit or deny action.
2. Processing stops after the first match.
3. Entries below the matching ACE are not examined for that packet.
4. If no explicit ACE matches, the packet is denied by the implicit deny at the end of every ACL.

Because processing stops at the first match, ACE order determines the result. Traffic that should be allowed must have an explicit permit entry before the packet reaches either a broad deny entry or the implicit deny.

Why Order Matters

This ACL does not allow the administrator, even though a permit entry appears later:

access-list 1 deny 10.0.0.0 0.0.0.255
access-list 1 permit host 10.0.0.5

The first entry matches 10.0.0.5, so the router denies the packet immediately. The later permit is never reached for that source.

Put the specific exception first:

access-list 1 permit host 10.0.0.5
access-list 1 deny 10.0.0.0 0.0.0.255

Now the administrator matches the first ACE and is permitted. Other sources in 10.0.0.0/24 match the second ACE and are denied.

The Implicit Deny

Conceptually, every ACL ends with:

deny any

This final rule is normally not displayed as a typed ACE, but its effect is present. An ACL containing only a permit for one host denies every other source that reaches it. If other sources must also be allowed, add an explicit permit such as permit any after the more specific entries.

Numbered Standard ACL Syntax

Numbered standard ACLs are created in global configuration mode. Standard IPv4 ACL numbers use either range 1–99 or range 1300–1999.

The general syntax is:

access-list <acl-number> permit|deny <source-ip> <wildcard-mask>
access-list <acl-number> permit|deny host <source-ip>
access-list <acl-number> permit|deny any

permit allows a matching packet to continue through the router. deny discards a matching packet. The address and wildcard mask identify which source addresses match.

Single-Host Matching

These two entries represent the same exact host match:

access-list 10 permit 10.0.0.5 0.0.0.0
access-list 10 permit host 10.0.0.5

The host keyword is shorthand for an address followed by the all-zero wildcard mask. An exact host match can also be written as:

access-list 10 permit 10.0.0.5 0.0.0.0

Matching Any Source

The any keyword matches every IPv4 source address:

access-list 10 permit any

Its address-and-wildcard equivalent is:

access-list 10 permit 0.0.0.0 255.255.255.255

Use a broad entry such as permit any only after specific deny or permit decisions that must take precedence.

Wildcard Masks and Source Matching

A wildcard mask tells an ACL which bits of an address must match and which bits may vary. It is not a subnet mask, although it often looks related to one.

• A wildcard bit of 0 requires the corresponding address bit to match exactly.
• A wildcard bit of 1 ignores the corresponding address bit, allowing it to vary.

For a single host, every bit must match, so the wildcard mask is 0.0.0.0. For the entire 10.0.0.0/24 network, the first 24 bits must match and the final 8 bits may vary, producing wildcard mask 0.0.0.255.

The selected source range is important. Permitting 10.0.0.0 0.0.0.255 permits every source in that /24, not just 10.0.0.5. Conversely, permitting host 10.0.0.5 does not permit other hosts in the same network.

Applying an ACL to an Interface

Creating an ACL does not filter traffic by itself. The ACL must be attached to a router interface with the ip access-group command.

interface <interface-id>
 ip access-group <acl-number> in
 ip access-group <acl-number> out

An inbound ACL evaluates a packet as it enters an interface. An outbound ACL evaluates a packet after routing has selected that interface and just before the packet leaves it. “Inbound” and “outbound” are always interpreted from the router's perspective.

ACLs are attached per interface and per direction. An interface can have an inbound ACL and an outbound ACL, but it should not have multiple IPv4 ACLs applied simultaneously in the same direction. To replace an existing ACL in a direction, remove or change the current attachment as appropriate.

Where to Place a Standard ACL

The usual recommendation is to place a standard ACL as close to the destination as practical. Since a standard ACL can see only the source address, placing it near the source may block that source from reaching multiple destinations, even when only one destination was intended to be protected.

For example, an outbound standard ACL on the interface leading to a server network can protect that specific destination network. The same source traffic can continue toward other interfaces unless another policy affects it.

This recommendation is a guideline, not a substitute for traffic-flow analysis. If filtering must distinguish destinations, protocols, or ports, use an extended ACL instead.

End-to-End Example: Protecting a Server Network

Assume R1 connects two client networks to a server LAN. The server network is 192.168.0.0/24, and the protected server is 192.168.0.5/24. The administrator workstation is 10.0.0.5/24. The unwanted client is 172.16.0.10/24. R1's FastEthernet0/1 interface leads to the server LAN.

The requirement is to permit the administrator to reach the server and deny the unwanted client. The ACL is applied outbound on the server-facing interface because the filtering decision is intended for traffic leaving R1 toward the server network.

R1# configure terminal
R1(config)# access-list 1 permit host 10.0.0.5
R1(config)# access-list 1 deny host 172.16.0.10
R1(config)# interface FastEthernet0/1
R1(config-if)# ip access-group 1 out
R1(config-if)# end

The permit is intentionally listed before the deny. The explicitly denied client is listed before the implicit deny so that the policy documents and counts that denial directly. Sources not matching either entry still reach the implicit deny and are also blocked.

Because this is a standard ACL, the decision is based on the source address. The ACL does not know whether the destination is the server's web service, an SSH service, or another destination reached through the server-facing interface.

Verification and Safe Operations

After configuration, verify both the ACL contents and its interface attachment. These commands are useful from privileged EXEC mode:

show access-lists
show ip access-lists
show ip interface
show running-config

show access-lists and show ip access-lists display ACEs in processing order. They may also show match counters, which increase when packets match an entry. Counters help determine whether test traffic is reaching the expected permit or deny rule.

show ip interface reports ACLs applied to an interface and identifies whether they are inbound or outbound. show running-config lets you inspect the ACL definition and the interface configuration together.

1. Confirm the tested host's actual source address.
2. Confirm the ACL contains the intended host or network match.
3. Check that the specific permit appears before broader entries.
4. Confirm the ACL is applied to the expected interface and direction.
5. Test from a permitted host, an explicitly denied host, and an unspecified host.
6. Review match counters after each test.

Troubleshooting Common Problems

All Clients, Including the Administrator, Are Blocked

• The administrator's actual source address does not match the permit entry.
• A broader deny entry appears before the administrator's permit.
• The ACL is applied to the wrong interface or direction.
• The administrator lacks an expected permit and reaches the implicit deny.

Use show ip access-lists to inspect order and counters. Use show ip interface to confirm attachment and direction. Verify the source address generated by the test host rather than assuming it from the physical network.

The Intended Blocked Client Can Still Reach the Server

• The ACL is not attached to the server-facing interface.
• The ACL is attached inbound instead of outbound for the designed traffic path.
• The client uses a different source address, possibly because of address translation.
• A preceding permit matches the client before the deny is evaluated.

Trace the packet path through R1, review ACE order and counters, and confirm the source address observed by the router.

A Standard ACL Blocks Multiple Destinations

This commonly happens when a source-only ACL is placed near the source. The ACL cannot distinguish the intended destination from other destinations. Move the standard ACL closer to the protected destination when appropriate. If the policy needs destination, protocol, or port criteria, use an extended ACL.

The ACL Exists but Has No Effect

• The ACL was created in global configuration mode but never applied with ip access-group.
• It was attached to an interface that the tested traffic does not traverse.
• The chosen direction does not match the packet's movement through the router.

Check show running-config and show ip interface, then generate test traffic and inspect the ACL match counters.

Key Points to Remember

• A standard IPv4 ACL matches only the source IPv4 address.
• ACE processing is top-down and stops at the first match.
• Every ACL has an implicit final deny for unmatched traffic.
• Wildcard mask bit 0 means “must match”; bit 1 means “ignore.”
• host matches one exact source, while any matches every IPv4 source.
• Creating an ACL is not enough; attach it with ip access-group.
• Inbound means entering the router interface; outbound means leaving it.
• Place standard ACLs close to the destination when practical.
• Use verification commands and counters before assuming the policy works.