CCNA Access Control Lists: Standard vs Extended, Numbered vs Named, Wildcard Masks and Placement

ACL questions punish small slips: one wrong wildcard bit, one line in the wrong order, one ACL on the wrong interface. The rules behind them are few and fixed, so the work is in applying them exactly, every time.

What CCNA objective 4.6 asks about ACLs

The v2.0 exam topics, which apply from February 3, 2027, list objective 4.6: "Configure IPv4 access control lists (standard, extended, numbered, and named ACLs)." The v1.1 outline, in use through February 2, 2027, asks you to configure and verify access control lists (5.6). The v2.0 wording names all four forms and limits the objective to IPv4.

Standard vs extended, numbered vs named ACLs

Two separate choices define an ACL: what it can match, and how you identify it. Cisco's IP access list document gives the details:

Cisco's common ACL examples add that extended ACLs can also filter on DSCP, precedence and the TCP SYN bit, none of which the CCNA objective names. Names don't change what an ACL can do. They make it readable and, as the next sections show, easier to edit.

Wildcard masks for CCNA ACLs

ACLs use wildcard masks, not subnet masks. Cisco's document puts the rule simply: each 0 in the wildcard means the bit must match exactly, and each 1 means the bit is ignored. For a whole subnet, subtract each octet of the subnet mask from 255:

Two shortcuts from Cisco's document: host 10.1.1.2 is the same as 10.1.1.2 0.0.0.0, and any is the same as 0.0.0.0 255.255.255.255. Cisco's own example, access-list 10 permit 192.168.148.0 0.0.1.255, covers 192.168.148.0 through 192.168.149.255: two /24s in one entry. If the wildcard math feels slow, the block sizes in the CCNA subnetting guide are the same numbers minus one.

How a router reads an ACL: first match and the implicit deny

Cisco's examples document states the core rules:

• Top to bottom, one entry at a time. The router tests a packet against each condition in order.
• First match wins. The router stops at the first matching entry, so order is critical.
• Implicit deny. If no entry matches, the packet is rejected because of an implicit deny all at the end of every ACL. Cisco's access list document adds that an ACL needs at least one permit, or all traffic is blocked.
• No effect until applied. Cisco's access list document notes that ACLs have no effect until they're applied to an interface, with ip access-group NAME in or out.

Editing has its own traps. Cisco's document shows that no access-list 101 deny icmp any any, typed in global configuration, deletes the whole numbered ACL, not just that line. New entries go to the end. The safer way is ACL configuration mode, where entries carry sequence numbers (10, 20, 30): ip access-list extended 101 lets you insert 5 deny tcp any any eq telnet above the first line, and no 20 removes one entry. Each interface takes one IPv4 ACL per direction, so applying a second ACL in the same direction replaces the first.

Rules like these are easier to hold onto with a hook. Memory tricks from AI Rescue, planned for launch, are one way to make first-match logic stick.

Where to apply an ACL: inbound, outbound and placement

Cisco's document defines direction from the router's point of view. An inbound ACL checks packets as they arrive on the interface, before routing. An outbound ACL checks packets after they've been routed to the interface and before they leave.

On placement, Cisco calls it good practice to apply an ACL on the interface closest to the source of the traffic, so unwanted packets are dropped early. That works cleanly for extended ACLs, which also match the destination. A standard ACL matches only the source, so placed near the source it can block that source from every destination. That's why CCNA study materials usually place standard ACLs close to the destination. Example 1 below shows the difference.

One related command: to limit which hosts can open SSH or Telnet sessions to the router itself, apply a standard ACL to the VTY lines with access-class 10 in under line vty 0 4, rather than ip access-group on an interface.

Original CCNA ACL examples

Written by Passy for practice; not taken from any Cisco exam. R1 has three LANs: users on G0/0 (192.168.10.0/24), servers on G0/1 (10.1.1.0/24) and a lab on G0/2 (192.168.20.0/24).

Example 1: block one PC from the servers with a standard named ACL. Host 192.168.10.50 must not reach 10.1.1.0/24. Everything else stays open.

ip access-list standard NO-PC50-TO-SERVERS
 deny host 192.168.10.50
 permit any
!
interface GigabitEthernet0/1
 ip access-group NO-PC50-TO-SERVERS out

Why outbound on G0/1: the ACL then sees only traffic headed for the server LAN. Applied inbound on G0/0, the same ACL would also cut the PC off from the lab and every other network beyond R1. Without permit any, the implicit deny would block everyone else too.

Example 2: allow only HTTPS from the lab to one server with an extended numbered ACL. Lab hosts may reach 10.1.1.10 on TCP 443 and nothing else on 10.1.1.0/24. All other lab traffic is allowed.

access-list 110 permit tcp 192.168.20.0 0.0.0.255 host 10.1.1.10 eq 443
access-list 110 deny ip 192.168.20.0 0.0.0.255 10.1.1.0 0.0.0.255
access-list 110 permit ip any any
!
interface GigabitEthernet0/2
 ip access-group 110 in

Why inbound on G0/2: an extended ACL can name the destination, so it can sit close to the source without blocking anything else. The server's replies enter on G0/1, so this ACL never sees them.

Example 3: the line that never matches. An engineer wants host 10.1.1.5 to pass while the rest of 10.0.0.0/8 is blocked, and applies:

access-list 120 deny ip 10.0.0.0 0.255.255.255 any
access-list 120 permit ip host 10.1.1.5 any
access-list 120 permit ip any any

Keyed answer: 10.1.1.5 is still blocked. It matches the first line, and processing stops there. The fix is to put the host entry first, for example with ip access-list extended 120 and then 5 permit ip host 10.1.1.5 any.

Example 4: a subnet mask where a wildcard belongs. access-list 30 permit 192.168.1.0 255.255.255.0 is meant to permit 192.168.1.0/24. Keyed answer: it doesn't. With 255.255.255.0 as a wildcard, the first three octets are ignored and the last must be 0, so it matches addresses ending in .0, and ordinary hosts like 192.168.1.10 fall through to the implicit deny. The wildcard should be 0.0.0.255.

One more trap from Cisco's document: an inbound ACL on a client-facing interface drops DHCP requests unless it permits them, because a client asks for an address from source 0.0.0.0 to destination 255.255.255.255, UDP source port 68 to destination port 67.

Verifying ACLs on a Cisco router

• show access-lists shows every ACL with its sequence numbers and a match count per entry. An entry that should be matching but stays at zero points to the wrong order, wildcard or interface.
• show ip interface GigabitEthernet0/1 shows which ACL is applied inbound and outbound on that interface.
• Test from both sides. A ping or connection from a permitted host and from a denied host should both behave as planned before you trust the configuration.

ACLs belong to Domain 4.0, Network Services and Security, and the 160 Network Services and Security questions planned for launch span that whole domain.

Practicing CCNA ACL questions

1. Translate requirements into lines on paper first: source, destination, protocol, port, permit or deny. Then decide the interface and direction.
2. Read every ACL you write from the top, as the router would, with three test packets: one that should pass, one that should be blocked, and one you didn't plan for.
3. Lab it. Build Examples 1 and 2 in Packet Tracer or Cisco Modeling Labs and watch the match counters. The CCNA lab practice guide compares the tools.

The 20 free CCNA practice questions include an ACL wildcard item with a worked explanation. Once you can write ACLs without second-guessing the order, the Perfect 10 challenge, planned for full CCNA prep, is one of several focused challenges for keeping the skill sharp. Checkout isn't open yet.