How to Configure a Standard ACL on Cisco (with Examples)

Step 1 — Write a numbered standard ACL

Numbered standard ACLs live in the ranges 1-99 (and 1300-1999 if you run out of the first block). Each line is a permit or deny matched against the packet's source address, followed by a wildcard mask — the inverse of a subnet mask — that says which bits to check. 0.0.0.255 matches a whole /24; 0.0.0.0 matches one exact host. Here we permit the HR subnet, 192.168.10.0/24, and nothing else.

Two shortcuts save you the wildcard math: 'host 192.168.10.5' is identical to '192.168.10.5 0.0.0.0' (one address), and 'any' is identical to '0.0.0.0 255.255.255.255' (every address). The router reads the list top-down and stops at the first match, so order your lines from most specific to most general.

R1(config)# access-list 10 remark Permit HR subnet only
R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255

Step 2 — Apply it close to the destination

This is the rule that sets standard ACLs apart from extended ones. Because a standard ACL matches only the source, applying it near the source would block that source from reaching everything, not just the one place you care about. Put it on the interface closest to the destination instead — here, the interface R1 uses to reach the protected server subnet — and apply it outbound so it filters traffic on its way out to that segment.

One ACL applies per interface, per direction. With ACL 10 permitting only the HR subnet, everything else — including any Guest traffic — is dropped on its way to the server, which is exactly the whitelist behavior we want here.

Verify right away: 'show access-lists 10' prints each line with a hit counter so you can watch the right traffic match, and 'show ip interface' confirms the ACL is bound in the direction you intended.

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip access-group 10 out
R1(config-if)# end
R1# show access-lists 10
R1# show ip interface gigabitethernet0/1

Step 3 — Use a named ACL to deny, then permit

When the policy is a blacklist — block one subnet, allow everyone else — a named standard ACL reads better and is far easier to change later. 'ip access-list standard <name>' drops you into a sub-mode where each line gets an automatic sequence number, so you can insert or remove a single entry by number instead of rebuilding the whole list the way a classic numbered ACL forces you to.

Here we deny the Guest subnet and then explicitly permit everyone else. That trailing 'permit any' is not optional padding — it's load-bearing, for the reason we cover in Step 4.

R1(config)# ip access-list standard BLOCK-GUEST
R1(config-std-nacl)# deny 192.168.20.0 0.0.0.255
R1(config-std-nacl)# permit any

Step 4 — Account for the implicit deny any

Every ACL you write — standard or extended, numbered or named — ends with an invisible 'deny any' that never appears in the configuration. You won't see it in 'show run' or 'show access-lists', but it's always there as the final line, and it's why an ACL can never 'fall through' to permit: anything that matches no explicit line is dropped.

That implicit deny cuts both ways. In Step 1's HR list it's doing exactly what we want: after 'permit 192.168.10.0 0.0.0.255', the invisible 'deny any' silently drops every other source, so only HR reaches the server. But flip the goal to Step 3's — block just the Guest subnet and leave everyone else alone — and that same invisible deny becomes a trap: a list containing only 'deny 192.168.20.0 0.0.0.255' would drop all traffic that wasn't the Guest subnet right along with it, including hosts you never meant to filter. That's why Step 3 finished with 'permit any' — without it, denying Guest would silently deny the entire network.

Standard ACLs also make a clean tool for restricting remote management: apply one to the VTY lines with 'access-class <acl> in' instead of 'ip access-group', so only your admin subnet can open a Telnet or SSH session to the device. Notice in the output below that neither list shows the implicit deny — it's enforced but never printed.

R1# show access-lists
Standard IP access list 10
    10 permit 192.168.10.0, wildcard bits 0.0.0.255
Standard IP access list BLOCK-GUEST
    10 deny   192.168.20.0, wildcard bits 0.0.0.255
    20 permit any

Common mistakes (and the fix)

Placing the ACL near the source. A standard ACL only knows the source address, so applied near the source it blocks that host from reaching every destination, not just the one you meant to protect. Move it to the interface closest to the destination and apply it there.

An all-deny list that blocks everything. Because of the implicit 'deny any', a standard ACL that contains only deny statements permits nothing at all — the denies match their targets and the invisible deny catches everyone else. If you mean 'block these, allow the rest,' you must end with an explicit 'permit any'.

Using a subnet mask where a wildcard mask belongs. IOS reads the second value as a wildcard (inverse) mask, so typing 255.255.255.0 instead of 0.0.0.255 matches the wrong bits entirely. Wildcard equals the inverse of the subnet mask — a /24 is 0.0.0.255.

Order that shadows a line. The router stops at the first match, so a broad 'permit any' placed above a specific 'deny' means the deny never runs. List specific entries first, general ones last.

Applying it in the wrong direction. 'ip access-group ... in' versus 'out' matters — use 'show ip interface' to confirm the ACL is bound in the direction the traffic actually flows relative to that interface.

Trying to edit a classic numbered ACL in place. 'no access-list 10' removes the entire ACL at once, not a single line. Reach for a named standard ACL (or sequence numbers) whenever a list will change over time, so you can add or delete one entry without disturbing the rest. Building and grading this against a known-good answer key on real IOS is the fastest way to catch a wildcard or placement slip before it costs you on the exam.