ACLs – Access Control Lists Overview

1. What Is an ACL and Why Does It Matter?

An Access Control List (ACL) is an ordered set of rules — called Access Control Entries (ACEs) — that a Cisco router or multilayer switch uses to filter IP packets. Each ACE contains a permit or deny action followed by match criteria. When a packet is evaluated against an ACL, each ACE is checked in sequence from top to bottom. The first ACE that matches the packet determines what happens to it — the remaining ACEs are ignored. A packet that matches no ACE hits the implicit deny all at the end of every ACL.

ACLs are used for three primary purposes:

Purpose	Example
Security filtering	Block traffic from untrusted networks, deny specific hosts from reaching servers, restrict management access to authorised IPs only
Traffic classification	Identify traffic for QoS marking, NAT translation, Policy-Based Routing, or route map matching
VPN and route control	Define interesting traffic for IPsec VPN crypto maps, control route redistribution between routing protocols

2. How ACL Processing Works — Top-Down Order

Understanding the top-down processing model is the single most important ACL concept. Every matching decision follows this logic exactly.

  ACL processing flow for an incoming packet:

  Packet arrives at interface
         │
         ▼
  ACE 1: Does the packet match? ──► YES → apply permit/deny action → DONE (stop)
         │ NO
         ▼
  ACE 2: Does the packet match? ──► YES → apply permit/deny action → DONE (stop)
         │ NO
         ▼
  ACE 3: Does the packet match? ──► YES → apply permit/deny action → DONE (stop)
         │ NO
         ▼
  (no more ACEs)
         │
         ▼
  Implicit deny all → packet DROPPED (no log generated by default)

  Key rules:
  1. Evaluation is TOP-DOWN — first match wins, remaining ACEs are skipped
  2. Once a match is found, the action (permit/deny) is applied immediately
  3. If NO ACE matches → implicit deny all drops the packet silently
  4. Order of ACEs matters enormously — more specific entries must come BEFORE
     less specific ones (a broad permit before a specific deny = the deny never fires)

Order Matters — A Common Mistake

  WRONG ORDER — the deny for 10.1.1.1 can never be reached:

  ACE 1: permit 10.1.1.0 0.0.0.255   ← permits the entire /24 subnet
  ACE 2: deny   10.1.1.1 0.0.0.0     ← intended to block .1 specifically

  Packet from 10.1.1.1 arrives:
  → ACE 1: source 10.1.1.1 matches 10.1.1.0/24 → PERMIT → stop → .1 is allowed!
  ACE 2 is NEVER reached.

  CORRECT ORDER — specific before general:

  ACE 1: deny   10.1.1.1 0.0.0.0     ← block .1 specifically (most specific first)
  ACE 2: permit 10.1.1.0 0.0.0.255   ← allow the rest of the /24
  ACE 3: (implicit deny all)

  Packet from 10.1.1.1: ACE 1 matches → DENY ✓
  Packet from 10.1.1.5: ACE 1 no match → ACE 2 matches → PERMIT ✓

Golden rule: Always place the most specific ACEs at the top of the ACL and least specific (broader) ACEs lower down. A permit or deny for a single host must appear before any permit or deny that covers the subnet that host belongs to.

3. The Implicit Deny All

Every ACL on a Cisco device ends with an implicit deny all — an invisible ACE that denies any packet not matched by an explicit ACE above it. It is not shown in the running-configuration or in show access-lists output, but it is always present and always active.

  What you configure:                What the router actually processes:
  ──────────────────────────────     ──────────────────────────────────────
  permit 192.168.1.0 0.0.0.255       permit 192.168.1.0 0.0.0.255
  permit 10.0.0.0 0.255.255.255      permit 10.0.0.0 0.255.255.255
                                     deny   any any          ← IMPLICIT (invisible)

  A packet from 172.16.5.5:
  → ACE 1: no match (not in 192.168.1.0/24)
  → ACE 2: no match (not in 10.0.0.0/8)
  → Implicit deny: packet DROPPED — silently, no log entry

The most common ACL mistake: An administrator creates an ACL with only deny statements, not realising the implicit deny already blocks everything. Alternatively, they create an ACL with only one permit for a specific host, not realising the implicit deny blocks all other traffic. Always end an ACL with an explicit permit any if you want non-matched traffic to pass, or verify your intent matches what the implicit deny provides.

Making the Implicit Deny Visible with Logging

  ! Add an explicit deny any with log to see what is being dropped:
  Router(config)# ip access-list extended FILTER_INBOUND
  Router(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 any eq 80
  Router(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 any eq 443
  Router(config-ext-nacl)# deny ip any any log   ← makes drops visible in syslog

  ! Without "log", the implicit deny drops silently.
  ! "log" generates a syslog message for every denied packet — use carefully
  ! on high-traffic interfaces as it consumes CPU resources.

See show logging to review the syslog messages generated by the log keyword and Syslog for forwarding them to a central server.

4. Wildcard Masks

ACLs use wildcard masks instead of subnet masks to define which bits of an IP address must match. The logic is inverted from a subnet mask: a 0 bit in the wildcard means "must match this bit exactly" and a 1 bit means "this bit can be anything (ignore it)."

  Subnet mask vs Wildcard mask logic:

  Subnet mask:   255.255.255.0  →  1 bits = network, 0 bits = host
  Wildcard mask:   0.  0.  0.255 →  0 bits = must match, 1 bits = ignore

  Relationship: wildcard mask = 255.255.255.255 − subnet mask
  Example: subnet /24 = 255.255.255.0 → wildcard = 0.0.0.255

  ACL example — permit the 192.168.10.0/24 subnet:
  permit 192.168.10.0 0.0.0.255
         ───────────  ─────────
         Base address  Wildcard (match first 24 bits, ignore last 8)

  This matches: 192.168.10.0 through 192.168.10.255

  Common wildcard masks:
  ┌──────────────────┬──────────────────┬─────────────────────────────────────┐
  │  Subnet Mask     │  Wildcard Mask   │  Matches                            │
  ├──────────────────┼──────────────────┼─────────────────────────────────────┤
  │  255.255.255.255 │  0.0.0.0         │  Single host (exact match)          │
  │  255.255.255.0   │  0.0.0.255       │  /24 subnet (256 addresses)         │
  │  255.255.0.0     │  0.0.255.255     │  /16 range (65,536 addresses)       │
  │  255.0.0.0       │  0.255.255.255   │  /8 range (16.7M addresses)         │
  │  0.0.0.0         │  255.255.255.255 │  All addresses (any)                │
  └──────────────────┴──────────────────┴─────────────────────────────────────┘

Wildcard Mask Shortcuts — host and any

  Cisco IOS provides two keywords to avoid typing common wildcard masks:

  "host" keyword — matches a single IP address exactly:
  deny host 192.168.1.5
  ≡ deny 192.168.1.5 0.0.0.0   (identical — wildcard 0.0.0.0 = match all bits)

  "any" keyword — matches any IP address:
  permit any
  ≡ permit 0.0.0.0 255.255.255.255  (identical — wildcard all bits = any address)

  Examples in an ACL:
  deny   host 10.1.1.1          ! deny exactly 10.1.1.1
  permit 10.1.1.0 0.0.0.255     ! permit the rest of the /24
  permit any                    ! permit everything else

See full guide: Wildcard Masks

5. Standard ACLs

Standard ACLs filter traffic based solely on the source IP address. They cannot examine the destination address, protocol, or port number. Because they only look at the source, they must be placed as close to the destination as possible — placing them near the source would block that source from reaching all destinations, not just the intended one.

Feature	Standard ACL
Match criteria	Source IP address only
Numbered range	1–99 and 1300–1999
Named	Yes — `ip access-list standard <name>`
Placement rule	Place close to the destination to avoid over-blocking traffic to other networks
Common uses	Restricting VTY (SSH/Telnet) access, controlling route redistribution, basic source-based filtering

  Standard ACL syntax:

  Numbered:
  Router(config)# access-list 10 deny   host 192.168.1.5
  Router(config)# access-list 10 permit 192.168.1.0 0.0.0.255
  Router(config)# access-list 10 deny   any

  Named:
  Router(config)# ip access-list standard BLOCK_HOST
  Router(config-std-nacl)# deny   host 192.168.1.5
  Router(config-std-nacl)# permit 192.168.1.0 0.0.0.255
  Router(config-std-nacl)# deny   any

  Applying to VTY lines (restricting management access):
  Router(config)# line vty 0 4
  Router(config-line)# access-class BLOCK_HOST in

Standard ACL Placement — Why Close to Destination?

  Topology:
  [Host A: 10.1.1.1] ── [R1] ── [R2] ── [Server 172.16.1.10]
                                    └──── [Server 172.16.2.10]

  Goal: Block Host A from reaching Server 172.16.1.10 only.

  WRONG — ACL on R1 (close to source):
  ACL: deny host 10.1.1.1
  Applied inbound on R1's LAN interface.
  Result: Host A cannot reach EITHER 172.16.1.10 OR 172.16.2.10
  Standard ACL can only match source — it blocks the host from everything.

  CORRECT — ACL on R2 (close to destination):
  ACL: deny host 10.1.1.1
  Applied outbound on R2's interface toward 172.16.1.10.
  Result: Host A cannot reach 172.16.1.10 ✓
          Host A CAN still reach 172.16.2.10 ✓

See full guide: Standard ACLs | Standard ACL Lab

6. Extended ACLs

Extended ACLs can match on multiple criteria simultaneously: source IP, destination IP, Layer 4 protocol (TCP, UDP, ICMP, etc.), source port, and destination port. This makes them far more precise and flexible than standard ACLs. Because they can match the destination, extended ACLs should be placed as close to the source as possible — this stops unwanted traffic early and avoids wasting bandwidth on traffic that will eventually be blocked.

Feature	Extended ACL
Match criteria	Source IP, destination IP, protocol (IP, TCP, UDP, ICMP, OSPF, EIGRP, etc.), source port, destination port, TCP flags (established), DSCP, ToS
Numbered range	100–199 and 2000–2699
Named	Yes — `ip access-list extended <name>`
Placement rule	Place close to the source to drop traffic early and conserve bandwidth
Common uses	Firewall-style filtering, permitting specific applications (HTTP, SSH, DNS), blocking specific protocols, NAT interesting traffic, VPN crypto maps, PBR matching, and complementing DHCP Snooping / 802.1X access control

  Extended ACL syntax:

  access-list <number> {permit|deny} <protocol> <src> <src-wildcard> <dst> <dst-wildcard> [operator port]

  Protocol keywords: ip, tcp, udp, icmp, ospf, eigrp, esp, ahp, gre, …
  Port operators:    eq (equal), neq (not equal), lt (less than),
                     gt (greater than), range (range of ports)

  Examples:

  ! Permit HTTP from any source to the web server 172.16.1.10:
  access-list 110 permit tcp any host 172.16.1.10 eq 80

  ! Permit HTTPS from the 10.1.0.0/16 network to any destination:
  access-list 110 permit tcp 10.1.0.0 0.0.255.255 any eq 443

  ! Deny all ICMP from 192.168.5.0/24 to any destination:
  access-list 110 deny icmp 192.168.5.0 0.0.0.255 any

  ! Permit DNS (UDP port 53) from internal to DNS server:
  access-list 110 permit udp 10.0.0.0 0.255.255.255 host 8.8.8.8 eq 53

  ! Permit established TCP sessions (return traffic):
  access-list 110 permit tcp any 10.0.0.0 0.255.255.255 established

  ! Deny everything else (explicit — good practice alongside implicit):
  access-list 110 deny ip any any log

The "established" Keyword

  The "established" keyword matches TCP packets that have the ACK or RST
  flag set — indicating the packet is part of an ALREADY established session
  (return traffic), not a new connection initiation (SYN).

  Use case: Allow internal hosts to browse the Internet (outbound permitted),
  and allow only return traffic back in (inbound established only).

  Inbound ACL on Internet-facing interface:
  permit tcp any 10.0.0.0 0.255.255.255 established   ← allow return TCP
  permit udp any 10.0.0.0 0.255.255.255               ← allow return UDP (stateless)
  deny   ip  any any log                               ← block everything else

  Note: "established" only works with TCP — UDP is stateless and has no flags.
  For stateful inspection of UDP and other protocols, use a proper firewall
  (Zone-Based Firewall or ASA).
  See: <a href="zone-based-firewall.html">Zone-Based Firewall</a>

See full guide: Extended ACL Lab

7. Numbered vs Named ACLs

Cisco IOS supports two ACL identification methods: numbered (identified by a number) and named (identified by a descriptive string). Both can be standard or extended. Named ACLs were introduced to address the limitations of numbered ACLs.

Feature	Numbered ACL	Named ACL
Identifier	A number (1–99, 100–199, 1300–1999, 2000–2699)	A descriptive name (e.g., BLOCK_TELNET, PERMIT_WEB)
Edit individual ACEs	Cannot delete individual lines — must delete the entire ACL and re-enter	Can delete or insert individual ACEs by sequence number
Sequence numbers	Not visible (added in modern IOS but limited)	Explicitly shown and editable — insert entries between existing ones
Readability	Low — number 110 gives no clue about purpose	High — PERMIT_HTTP_TO_SERVER is self-documenting
Recommended for	Simple/temporary filters, legacy environments	Production networks — best practice in all modern designs

Named ACL Sequence Numbers — Editing Without Rewriting

  Named ACL with sequence numbers:

  Router(config)# ip access-list extended CORP_FILTER
  Router(config-ext-nacl)# 10 permit tcp 10.1.0.0 0.0.255.255 any eq 80
  Router(config-ext-nacl)# 20 permit tcp 10.1.0.0 0.0.255.255 any eq 443
  Router(config-ext-nacl)# 30 permit tcp 10.1.0.0 0.0.255.255 any eq 22
  Router(config-ext-nacl)# 40 deny ip any any log

  ! Need to insert a new rule between seq 20 and seq 30?
  ! Use sequence number 25:
  Router(config-ext-nacl)# 25 permit tcp 10.1.0.0 0.0.255.255 any eq 53

  ! Need to delete only seq 30?
  Router(config-ext-nacl)# no 30

  ! With NUMBERED ACLs you cannot do this — you must:
  ! 1. Remove the entire ACL from the interface
  ! 2. Delete the entire ACL (no access-list 110)
  ! 3. Re-enter every ACE from scratch

  Verify ACL with sequence numbers:
  Router# show ip access-lists CORP_FILTER
  Extended IP access list CORP_FILTER
      10 permit tcp 10.1.0.0 0.0.255.255 any eq www (142 matches)
      20 permit tcp 10.1.0.0 0.0.255.255 any eq 443 (87 matches)
      25 permit tcp 10.1.0.0 0.0.255.255 any eq domain
      30 permit tcp 10.1.0.0 0.0.255.255 any eq 22
      40 deny ip any any log (3 matches)

See full guide: Named ACLs

8. ACL Number Ranges — Reference

ACL Type	Number Range	Match Criteria
Standard IP	1 – 99	Source IP address only
Extended IP	100 – 199	Source IP, destination IP, protocol, source/destination port
Standard IP (expanded)	1300 – 1999	Source IP address only (additional range)
Extended IP (expanded)	2000 – 2699	Source IP, destination IP, protocol, source/destination port (additional range)
Standard IPX	800 – 899	Legacy IPX — not relevant to CCNA
Extended IPX	900 – 999	Legacy IPX — not relevant to CCNA

CCNA exam numbers to memorise: Standard IP ACLs = 1–99 (and 1300–1999). Extended IP ACLs = 100–199 (and 2000–2699). If you see a numbered ACL in a question, the number immediately tells you whether it is standard or extended.

9. Inbound vs Outbound ACL Placement

An ACL is applied to a router interface in a specific direction — either inbound (filtering packets as they arrive on the interface) or outbound (filtering packets as they leave the interface). The direction determines which traffic the ACL sees and critically affects what other router processes (such as routing table lookup) have already occurred.

Inbound ACL

  Inbound ACL — applied on the interface where packets ARRIVE:

  [External network] ──► Gi0/0 (inbound ACL here) ──► routing table ──► Gi0/1

  Processing order:
  1. Packet arrives on Gi0/0
  2. Inbound ACL is evaluated BEFORE the routing table lookup
  3. If permit → routing table lookup → forwarded
  4. If deny  → packet dropped immediately — routing never consulted

  Advantage: Drops unwanted traffic early — before the CPU cost of routing
  Advantage: Protects the router itself from inbound attacks
  Use case:  Filter traffic entering the network from an untrusted source
             (e.g., inbound on WAN interface from the Internet)

Outbound ACL

  Outbound ACL — applied on the interface where packets LEAVE:

  [LAN] ──► Gi0/0 ──► routing table ──► Gi0/1 (outbound ACL here) ──► [Server]

  Processing order:
  1. Packet arrives on Gi0/0
  2. Routing table lookup determines exit interface (Gi0/1)
  3. Outbound ACL on Gi0/1 is evaluated BEFORE the packet leaves
  4. If permit → packet transmitted out Gi0/1
  5. If deny  → packet dropped at this point

  Advantage: Can filter based on egress interface — useful when traffic from
             multiple sources converges on one exit point
  Use case:  Restrict what leaves a specific interface toward a destination
             (e.g., permit only HTTP/HTTPS out the WAN interface)

Inbound vs Outbound — Key Differences

Feature	Inbound ACL	Outbound ACL
When evaluated	Before routing table lookup	After routing table lookup, before transmission
Affects router-originated traffic	No — packets generated by the router bypass inbound ACLs	Yes — packets generated by the router are subject to outbound ACLs
CPU efficiency	More efficient — drops packets before routing lookup	Less efficient — routing lookup already done when drop occurs
Typical use	Filter ingress traffic (from untrusted networks, WAN)	Restrict egress traffic (to specific destinations or servers)
ACLs per interface per direction	Maximum one ACL per interface per direction (one inbound + one outbound allowed simultaneously on the same interface)

Applying an ACL to an Interface

  ! Apply ACL to an interface:
  Router(config)# interface gigabitEthernet 0/0
  Router(config-if)# ip access-group CORP_FILTER in    ! inbound
  Router(config-if)# ip access-group OUTBOUND_FILTER out  ! outbound

  ! A different ACL can be applied inbound and outbound on the SAME interface.
  ! But only ONE ACL per direction per interface.

  ! Apply a standard ACL to VTY lines (restrict SSH/Telnet management access):
  Router(config)# line vty 0 4
  Router(config-line)# access-class MGMT_ALLOW in

  ! Remove an ACL from an interface:
  Router(config-if)# no ip access-group CORP_FILTER in

See full guide: Applying ACLs to Interfaces

10. ACL Placement Rules — Standard vs Extended Summary

The placement rule for each ACL type exists because of what each type can and cannot match. Understanding why the rules exist makes them impossible to forget.

ACL Type	Place Close To	Why
Standard ACL	Destination	Standard ACLs can only match source IP. Placing near the source would block that source from ALL destinations — not just the intended one. Placing near the destination ensures the block is specific to the path toward that destination.
Extended ACL	Source	Extended ACLs can match destination IP and port, so they can be precise about what is blocked. Placing near the source drops traffic early — before it wastes bandwidth traversing multiple router hops only to be blocked at the far end.

  Topology:
  [Finance: 10.10.1.0/24] ── [R1] ── [R2] ── [Server farm: 172.16.0.0/24]
  [HR:      10.20.1.0/24] ──┘

  Goal: Block Finance from accessing the HR file server (172.16.0.5 port 445)
        but allow Finance to access all other servers.

  Standard ACL approach — must go near destination (R2):
  deny   host 10.10.1.0 0.0.0.255   ← blocks Finance from ALL of R2's networks
  This is too broad — Finance also cannot reach web/mail servers behind R2.

  Extended ACL approach — place near source (R1, inbound on Finance interface):
  deny   tcp 10.10.1.0 0.0.0.255 host 172.16.0.5 eq 445   ← precise block
  permit ip  any any
  Result: Finance blocked only from 172.16.0.5:445; can reach everything else ✓
  Traffic is dropped at R1 — does not waste the R1→R2 link bandwidth.

11. ACL Best Practices

Best Practice	Reason
Use named ACLs in production	Self-documenting names, editable individual ACEs by sequence number — avoid the numbered ACL limitation of full rewrite on edit
Most specific ACEs first	Prevents broad rules from shadowing specific ones — ensure host-specific rules precede subnet rules
Add explicit `deny ip any any log` at the end	Makes the implicit deny visible in syslog for troubleshooting and security monitoring
Use remarks for documentation	`remark` lines explain purpose; visible in running-config and `show access-lists`
Test ACLs in a lab before production	An incorrectly placed ACL can cut off legitimate traffic — including your own management access
Always have a permit before applying an ACL to an interface	An ACL with only deny statements plus the implicit deny will block everything — verify at least one permit exists for legitimate traffic
One ACL per interface per direction	IOS only accepts one ACL inbound and one outbound per interface — consolidate rules into one ACL rather than applying multiple
Remove ACL from interface before deleting it	Deleting an ACL while it is applied to an interface removes the filter but may leave a reference — always remove with `no ip access-group` first

  Using remarks for documentation:

  Router(config)# ip access-list extended EDGE_FILTER
  Router(config-ext-nacl)# remark === Permit web traffic from internal LAN ===
  Router(config-ext-nacl)# 10 permit tcp 10.0.0.0 0.255.255.255 any eq 80
  Router(config-ext-nacl)# 20 permit tcp 10.0.0.0 0.255.255.255 any eq 443
  Router(config-ext-nacl)# remark === Block all other traffic and log ===
  Router(config-ext-nacl)# 30 deny ip any any log

12. Verification Commands

  ! Show all ACLs and their match counters:
  Router# show ip access-lists

  ! Show a specific named or numbered ACL:
  Router# show ip access-lists CORP_FILTER
  Router# show ip access-lists 110

  ! Show which ACLs are applied to which interfaces and in which direction:
  Router# show ip interface gigabitEthernet 0/0
  ...
  Inbound  access list is CORP_FILTER
  Outbound access list is not set

  ! Show running-config section for a specific ACL:
  Router# show running-config | section ip access-list

  ! Clear ACL hit counters (match statistics) without removing the ACL:
  Router# clear ip access-list counters CORP_FILTER
  Router# clear ip access-list counters          ! clears all ACL counters

Interpreting show ip access-lists Output

  Router# show ip access-lists CORP_FILTER

  Extended IP access list CORP_FILTER
      10 permit tcp 10.1.0.0 0.0.255.255 any eq www (2341 matches)
      20 permit tcp 10.1.0.0 0.0.255.255 any eq 443 (1876 matches)
      30 deny ip any any log (47 matches)

  Key fields:
  - Sequence number (10, 20, 30): order of evaluation
  - permit / deny: action applied on match
  - Match criteria: protocol, source, destination, port
  - (X matches): number of packets that matched this ACE since last counter clear
  - A count of 0 on a permit ACE may indicate misconfigured criteria
  - A high count on a deny ACE indicates traffic being blocked — investigate source

Troubleshooting tip: ACL match counters are your best friend when troubleshooting ACL issues. If a permit ACE has zero matches and traffic is being blocked, check whether a deny ACE above it is catching the traffic first (top-down order). If an unexpected deny ACE has high match counts, the traffic selector may be too broad. Be especially careful not to block routing protocol traffic — see OSPF and Default Routes for common interaction points.

13. ACL Summary — Key Facts

Topic	Key Fact
Processing order	Top-down — first match wins; remaining ACEs are not evaluated
Implicit deny	Every ACL ends with an invisible `deny any any` — unmatched traffic is always dropped
Standard ACL numbers	1–99 and 1300–1999 — matches source IP only
Extended ACL numbers	100–199 and 2000–2699 — matches source, destination, protocol, port
Standard ACL placement	Close to the destination — avoids over-blocking
Extended ACL placement	Close to the source — drops traffic early, saves bandwidth
Wildcard 0.0.0.0	Matches single host — equivalent to `host` keyword
Wildcard 255.255.255.255	Matches any address — equivalent to `any` keyword
Max ACLs per interface	One inbound + one outbound — only two ACLs per interface
Named vs numbered	Named ACLs allow individual ACE editing by sequence number; numbered ACLs require full rewrite to change one entry
Interface apply command	`ip access-group <name/number> in\|out`
VTY apply command	`access-class <name/number> in` — restricts SSH/Telnet management access

14. ACL Concepts Quiz

1. An ACL has three ACEs: permit 10.1.1.0/24, deny host 10.1.1.5, and permit any. A packet from 10.1.1.5 arrives. What happens?

A. The packet is denied because ACE 2 specifically blocks 10.1.1.5 B. The packet is permitted because ACE 3 (permit any) always applies C. The packet is permitted. ACE 1 matches first (10.1.1.5 is in the 10.1.1.0/24 subnet) — the permit action is applied immediately and ACE 2 is never evaluated. Top-down processing means first match wins. D. The packet is dropped by the implicit deny at the end of the ACL

Correct answer is C. This is the most important ACL exam scenario — it tests top-down processing and the ordering mistake. ACE 1 (permit 10.1.1.0/24) matches 10.1.1.5 because .5 is in the /24 subnet. The permit action is applied immediately and evaluation stops. ACE 2 is never reached. To correctly block 10.1.1.5, the deny for that specific host must appear BEFORE the broader subnet permit. The correct order is: deny host 10.1.1.5 → permit 10.1.1.0/24 → permit any.

2. What does the implicit deny do, and where does it appear in the ACL?

A. It permits all traffic that does not match any explicit ACE; it appears at the beginning of every ACL B. It silently drops any packet that does not match any explicit ACE. It exists invisibly at the end of every ACL — not shown in the running-config or show access-lists output — but is always evaluated last. C. It generates a syslog alert for unmatched packets and then permits them D. It only applies when the ACL has no permit statements

Correct answer is B. The implicit deny all is one of the most critical ACL concepts. It is an invisible deny ip any any that Cisco IOS appends to the end of every ACL. It does not appear in show running-config or show ip access-lists — yet it is always active. Any packet that reaches the end of the ACL without matching any explicit ACE is silently dropped. Importantly, no log entry is generated by the implicit deny — to log dropped traffic, add an explicit deny ip any any log as the last ACE.

3. A standard ACL numbered 15 is used to block a specific host from accessing a server. According to Cisco best practice, where should this ACL be applied?

A. Inbound on the source router's LAN interface, as close to the blocked host as possible B. Outbound on every router interface in the network C. On the router that connects to the ISP D. As close to the destination as possible — on the router interface nearest to the target server. Standard ACLs only match source IP and cannot specify a destination, so placing near the source would block the host from all destinations.

Correct answer is D. Standard ACLs can only match source IP — they have no awareness of destination. If a standard ACL denying host 10.1.1.5 is placed inbound on the source router's LAN interface, it blocks that host from reaching ALL destinations (not just the target server). By placing it close to the destination — outbound on the interface pointing toward the specific server — the block is limited to that specific path. The host can still reach other destinations through other interfaces.

4. What is the wildcard mask equivalent of the subnet mask 255.255.255.0, and what does it match in an ACL?

A. 0.0.0.255 — it matches any IP address where the first three octets match the base address exactly (the 0 bits must match), and the last octet can be any value (the 255 bits are ignored). For example: 192.168.1.0 0.0.0.255 matches 192.168.1.0–192.168.1.255. B. 255.255.255.0 — the wildcard mask is identical to the subnet mask C. 0.0.0.0 — matches a single host D. 1.1.1.0 — the inverted non-zero octets

Correct answer is A. Wildcard masks are calculated as 255.255.255.255 minus the subnet mask: 255.255.255.255 − 255.255.255.0 = 0.0.0.255. In a wildcard mask, 0 = must match this bit, 1 = ignore this bit. So 0.0.0.255 means: match the first three octets exactly, ignore the last octet. Applied to base address 192.168.1.0, this matches the entire /24 subnet: 192.168.1.0 through 192.168.1.255 — 256 addresses total.

5. How many ACLs can be applied to a single router interface, and what is the limitation?

A. Unlimited — as many ACLs as needed can be applied in each direction B. A maximum of one ACL per direction per interface — one inbound and one outbound. A total of two ACLs per interface (one in each direction). Attempting to apply a second ACL in the same direction replaces the existing one. C. One ACL total per interface — either inbound or outbound, not both D. Two per direction — four ACLs per interface total

Correct answer is B. Cisco IOS allows a maximum of one ACL per direction per interface. This means one inbound ACL and one outbound ACL can be applied to the same interface simultaneously — two total. If you attempt to apply a second ACL in the same direction (e.g., two inbound ACLs), the second application replaces the first. To filter on multiple criteria, all rules must be consolidated into a single ACL per direction. This is one reason named ACLs with many ACEs are preferred over multiple small ACLs.

6. What is the key advantage of named ACLs over numbered ACLs?

A. Named ACLs are processed faster by the router's CPU B. Named ACLs support extended matching criteria that numbered ACLs do not C. Named ACLs allow individual ACEs to be added, deleted, or reordered by sequence number without rewriting the entire ACL. They are also self-documenting through descriptive names. Numbered ACLs require deleting and re-entering the entire list to change one entry. D. Named ACLs automatically apply to all interfaces without needing ip access-group commands

Correct answer is C. The primary advantage of named ACLs is editability. Each ACE in a named ACL has a sequence number (auto-assigned at intervals of 10 by default). You can delete a specific ACE with no <sequence-number> and insert a new one between existing entries by specifying an intermediate sequence number (e.g., insert at seq 15 between seq 10 and seq 20). With numbered ACLs, there is no way to edit a single entry — you must remove the entire ACL (no access-list <number>), remove it from all interfaces, then re-enter every ACE from scratch.

7. An extended ACL is configured with: `permit tcp any 10.0.0.0 0.255.255.255 established`. What traffic does this ACE permit?

A. All TCP traffic initiating new connections to the 10.0.0.0/8 network B. All IP traffic (any protocol) from any source to 10.0.0.0/8 C. Only UDP return traffic from the Internet to 10.0.0.0/8 D. TCP packets with the ACK or RST flag set, from any source, destined to the 10.0.0.0/8 network — return traffic for already-established TCP sessions initiated by internal hosts. New TCP connections (SYN only) do not match "established."

Correct answer is D. The established keyword matches TCP packets that have the ACK or RST bit set in the TCP header. A brand new TCP connection starts with a SYN packet (only the SYN bit set — no ACK). Return traffic for an existing session carries ACK (plus possibly other flags). This ACE is typically used on an inbound ACL on the WAN interface — it allows return TCP traffic for sessions that internal hosts initiated, while blocking unsolicited inbound TCP connection attempts (which would only have SYN set and no ACK). Note: established only works for TCP — UDP has no connection flags.

8. An ACL is applied inbound on a router's WAN interface and outbound on the same interface. How does an inbound ACL differ from an outbound ACL in terms of when it is processed relative to the routing table?

A. An inbound ACL is processed BEFORE the routing table lookup — a denied packet is dropped immediately without the router performing any routing. An outbound ACL is processed AFTER the routing table lookup — the routing decision has already been made when the packet is evaluated at the egress interface. B. Both inbound and outbound ACLs are processed after the routing table lookup C. Inbound ACLs are processed after routing; outbound ACLs before routing D. The order relative to routing depends on the IOS version

Correct answer is A. This is a key architectural difference. When a packet arrives on an interface with an inbound ACL, the ACL is evaluated first. If denied, the packet is discarded before the router wastes CPU cycles on a routing table lookup. This makes inbound ACLs more efficient for dropping unwanted traffic. When a packet is routed and the exit interface has an outbound ACL, the routing table lookup has already occurred — the router knows where to send the packet. The outbound ACL then decides whether to actually send it. One practical implication: router-originated traffic (pings, routing updates from the router itself) bypasses inbound ACLs but is subject to outbound ACLs.

9. A network engineer adds a new ACE to a numbered ACL 110 using `access-list 110 permit tcp host 10.5.5.5 any eq 8080`. Where in the ACL does this new entry appear?

A. At the beginning of the ACL — new entries are prepended to the top B. At the bottom of the ACL — new entries added to a numbered ACL are always appended to the end, before the implicit deny. There is no way to insert an entry at a specific position in a numbered ACL. C. In alphabetical order based on the source IP address D. After any existing permit statements but before any deny statements

Correct answer is B. This is a critical limitation of numbered ACLs. When you add an ACE using access-list <number>, it is always appended to the end of the existing ACL. There is no way to specify a position. If you need to insert an entry before an existing one (e.g., a specific host permit before a broad deny), you must delete the entire numbered ACL (no access-list 110), remove it from all interfaces, and re-enter all ACEs in the correct order. This is why named ACLs with sequence numbers are strongly preferred in production environments — they allow targeted insertion and deletion.

10. An administrator wants to restrict SSH access to a router to only the management workstation at 192.168.99.10. They create a standard ACL 5 with `permit host 192.168.99.10`. What command applies this to the VTY lines, and what happens to SSH attempts from other IP addresses?

A. ip access-group 5 in under each VTY line; other attempts are silently dropped B. ip access-group 5 in under interface; other IP addresses receive an ICMP reject C. access-class 5 out under line vty 0 4; all other addresses are permitted by default D. access-class 5 in under line vty 0 4. Any SSH attempt from an IP other than 192.168.99.10 hits the implicit deny at the end of ACL 5 and is dropped — the connection is refused.

Correct answer is D. VTY access control uses access-class, not ip access-group. ip access-group is for physical/logical interfaces. access-class <acl> in under line vty 0 4 filters inbound connection attempts to the VTY lines. ACL 5 has one ACE: permit host 192.168.99.10. Any other source IP reaches the implicit deny and the connection is refused. This is the standard method for restricting SSH/Telnet management access to authorised IP addresses only. See: SSH Configuration | SSH Lab

← Back to Home

ACLs – Access Control Lists Overview

1. What Is an ACL and Why Does It Matter?

2. How ACL Processing Works — Top-Down Order

Order Matters — A Common Mistake

3. The Implicit Deny All

Making the Implicit Deny Visible with Logging

4. Wildcard Masks

Wildcard Mask Shortcuts — host and any

5. Standard ACLs

Standard ACL Placement — Why Close to Destination?

6. Extended ACLs

The "established" Keyword

7. Numbered vs Named ACLs

Named ACL Sequence Numbers — Editing Without Rewriting

8. ACL Number Ranges — Reference

9. Inbound vs Outbound ACL Placement

Inbound ACL

Outbound ACL

Inbound vs Outbound — Key Differences

Applying an ACL to an Interface

10. ACL Placement Rules — Standard vs Extended Summary

11. ACL Best Practices

12. Verification Commands

Interpreting show ip access-lists Output

13. ACL Summary — Key Facts

14. ACL Concepts Quiz

1. An ACL has three ACEs: permit 10.1.1.0/24, deny host 10.1.1.5, and permit any. A packet from 10.1.1.5 arrives. What happens?

2. What does the implicit deny do, and where does it appear in the ACL?

3. A standard ACL numbered 15 is used to block a specific host from accessing a server. According to Cisco best practice, where should this ACL be applied?

4. What is the wildcard mask equivalent of the subnet mask 255.255.255.0, and what does it match in an ACL?

5. How many ACLs can be applied to a single router interface, and what is the limitation?

6. What is the key advantage of named ACLs over numbered ACLs?

7. An extended ACL is configured with: permit tcp any 10.0.0.0 0.255.255.255 established. What traffic does this ACE permit?

8. An ACL is applied inbound on a router's WAN interface and outbound on the same interface. How does an inbound ACL differ from an outbound ACL in terms of when it is processed relative to the routing table?

9. A network engineer adds a new ACE to a numbered ACL 110 using access-list 110 permit tcp host 10.5.5.5 any eq 8080. Where in the ACL does this new entry appear?

10. An administrator wants to restrict SSH access to a router to only the management workstation at 192.168.99.10. They create a standard ACL 5 with permit host 192.168.99.10. What command applies this to the VTY lines, and what happens to SSH attempts from other IP addresses?

7. An extended ACL is configured with: `permit tcp any 10.0.0.0 0.255.255.255 established`. What traffic does this ACE permit?

9. A network engineer adds a new ACE to a numbered ACL 110 using `access-list 110 permit tcp host 10.5.5.5 any eq 8080`. Where in the ACL does this new entry appear?

10. An administrator wants to restrict SSH access to a router to only the management workstation at 192.168.99.10. They create a standard ACL 5 with `permit host 192.168.99.10`. What command applies this to the VTY lines, and what happens to SSH attempts from other IP addresses?