Exam Objective 4.6: Configure IPv4 access control lists (standard, extended, numbered, and named ACLs).
ACLs are one of the most fundamental security and traffic-control tools on a Cisco device, used to permit or deny traffic based on matching criteria, and also reused as matching mechanisms for other features already covered elsewhere in this blueprint (identifying interesting traffic for dynamic NAT in objective 4.3, for example). This objective expects you to configure standard and extended ACLs, in both numbered and named form, understand exactly how ACL processing logic works, and correctly place ACLs for the intended filtering effect.
An Access Control List is an ordered sequence of permit or deny statements (ACEs — Access Control Entries) that a router or switch evaluates against traffic, in order, applying the action of the first statement that matches. ACLs can be used for security filtering (blocking unwanted traffic), but also for identifying/classifying traffic for other features — NAT, route filtering, QoS classification, and VPN "interesting traffic" definitions all commonly reuse ACL syntax as their matching mechanism.
Core processing rules that apply to every ACL, without exception:
Statements are evaluated top-down, in the exact order they were configured
Processing stops at the first match — once a packet matches a statement (permit or deny), no further statements in that ACL are evaluated for that packet
There is an implicit deny all at the very end of every ACL, even though it's never displayed in the configuration — if a packet doesn't match any explicitly configured statement, it is denied by default
Because of the implicit deny, an ACL with only deny statements (and no explicit permit for legitimate traffic) will block everything
Exam Alert: The implicit deny at the end of every ACL is one of the most consistently tested ACL facts on the entire exam — forgetting to include at least one permit statement for legitimate traffic (or a final permit any/permit any any) is a classic real-world and exam-scenario mistake that silently blocks all traffic not explicitly permitted.
Standard ACLs:
Filter based only on source IP address — nothing else
Numbered range: 1–99, and an expanded range 1300–1999
Because they can only match source address, standard ACLs should generally be placed as close to the destination as possible, since filtering too early (close to the source) based only on source address risks blocking traffic that should have been allowed to reach other destinations
Example: access-list 10 permit 192.168.1.0 0.0.0.255
Extended ACLs:
Filter based on source IP address, destination IP address, protocol (TCP, UDP, ICMP, or others), and Layer 4 port numbers (source and/or destination), giving vastly more granular control
Numbered range: 100–199, and an expanded range 2000–2699
Because they can match on destination and protocol/port information as well, extended ACLs should generally be placed as close to the source as possible, blocking unwanted traffic immediately rather than letting it needlessly cross the network first only to be filtered right before its final destination
Example: access-list 110 permit tcp 192.168.1.0 0.0.0.255 host 10.1.1.100 eq 80
Exam Alert: The placement guidance — standard ACLs close to the destination, extended ACLs close to the source — is directly and frequently tested, and the underlying reasoning (standard ACLs can't distinguish between different destinations, so placing them too early risks unintentionally blocking traffic meant for other legitimate destinations) is worth understanding rather than just memorizing.
ACLs (along with OSPF network statements, covered in objective 3.3) use wildcard masks rather than standard subnet masks to define the range of addresses a statement should match.
How wildcard masks work: A 0 bit in the wildcard mask means that corresponding bit in the address must match exactly; a 1 bit means that corresponding bit can be anything (don't care). This is the logical inverse of a subnet mask.
Calculating a wildcard mask from a subnet mask: Subtract each octet of the subnet mask from 255. For example, a /24 network (255.255.255.0) becomes wildcard mask 0.0.0.255; a /28 network (255.255.255.240) becomes wildcard mask 0.0.0.15.
Special wildcard mask shortcuts:
host [address] — equivalent to a wildcard mask of 0.0.0.0, matching that exact single address only
any — equivalent to a wildcard mask of 255.255.255.255 applied to address 0.0.0.0, matching every possible address
Exam Alert: Know how to quickly calculate a wildcard mask from a given subnet mask or prefix length, and recognize host and any as shortcuts for the two extremes (match exactly one address, or match every address) — this calculation shows up constantly embedded within ACL configuration questions.
Numbered ACLs identify the ACL purely by a number within the appropriate range (1–99/1300–1999 for standard, 100–199/2000–2699 for extended), as shown in the examples above.
Named ACLs identify the ACL with a descriptive text name instead of a number, and are configured using a distinct syntax that enters a dedicated ACL configuration submode:
ip access-list standard BLOCK-GUEST-VLAN
deny 192.168.50.0 0.0.0.255
permit any
ip access-list extended ALLOW-WEB-TRAFFIC
permit tcp any host 10.1.1.100 eq 80
permit tcp any host 10.1.1.100 eq 443
deny ip any any
Advantages of named ACLs over numbered ACLs:
Descriptive, meaningful names make the ACL's purpose immediately clear from its name alone, rather than needing to remember what an arbitrary number like "110" was meant to accomplish
Named ACLs allow individual entries to be selectively removed or inserted at a specific sequence number without needing to delete and completely recreate the entire ACL — a capability numbered ACLs did not originally support (modern IOS versions do allow sequence-number-based editing of numbered ACLs too, but named ACLs were the original and more naturally structured way to gain this flexibility)
Both standard and extended ACLs can be configured as named ACLs, using the ip access-list standard or ip access-list extended keyword to specify which type is being created
Exam Alert: Named ACLs support both standard and extended types (specified explicitly via the ip access-list standard or ip access-list extended command), and their key practical advantage is descriptive naming plus easier line-by-line editing without needing to remove and rebuild the entire list.
Modern Cisco IOS assigns each ACL statement an internal sequence number (typically incrementing by 10 by default: 10, 20, 30, and so on), whether the ACL is numbered or named, allowing individual statements to be inserted, removed, or reordered without needing to delete and fully retype the entire ACL.
Viewing sequence numbers: show access-lists (or show ip access-lists)
Inserting a new statement at a specific position within a named ACL:
ip access-list extended ALLOW-WEB-TRAFFIC
15 permit tcp any host 10.1.1.100 eq 8080
This inserts a new statement between the existing sequence 10 and sequence 20 entries, without disturbing anything else in the ACL.
Exam Alert: Know that sequence numbers allow surgical insertion/removal of individual ACL entries — a very practical, real-world editing capability that's also directly testable as a specific IOS behavior.
An ACL does nothing on its own until it's actually applied somewhere — most commonly to an interface, in a specific direction.
interface GigabitEthernet0/1
ip access-group 110 in
ip access-group [number-or-name] [in | out] — applies the specified ACL to the interface, in the specified direction:
in — filters traffic as it enters the router through that interface, before any routing decision is made
out — filters traffic as it's about to exit the router through that interface, after the routing decision has already determined that this is the correct exit interface
Directionality is relative to the router, not the traffic's ultimate source/destination: "In" always means traffic coming into the router through that specific interface; "out" always means traffic leaving the router through that specific interface — this is a frequently tested point of confusion, since the same physical flow of traffic (say, from an internal host toward the internet) is "in" relative to the internal-facing interface and "out" relative to the internet-facing interface.
Only one ACL per protocol, per direction, per interface: A single interface can have at most one inbound ACL and one outbound ACL applied simultaneously (for a given protocol, like IPv4) — you cannot apply two separate ACLs to the same interface in the same direction.
Other places ACLs are commonly applied/referenced (beyond interface filtering), tying back to earlier objectives:
Identifying traffic for dynamic NAT/PAT translation (objective 4.3)
Controlling VTY line access (permitting only specific management-station source addresses to Telnet/SSH into the device)
Route filtering (controlling which routes are permitted to be advertised or accepted by a routing protocol)
Exam Alert: The in/out direction is always evaluated from the router's own perspective for that specific interface, never from the perspective of the original traffic source — this single point of confusion is one of the most commonly tested and most commonly misunderstood ACL concepts on the exam.
Extended ACLs can match on the specific Layer 4 protocol and port number(s) involved, using comparison operators to define the matching range.
Common protocol keywords: ip (matches all IP traffic regardless of Layer 4 protocol), tcp, udp, icmp, along with others.
Port comparison operators (used with tcp or udp):
eq [port] — matches only that exact port number
gt [port] — matches any port number greater than the specified value
lt [port] — matches any port number less than the specified value
range [start] [end] — matches any port number within the specified inclusive range
neq [port] — matches any port number except the specified value
Example combining several concepts:
access-list 110 permit tcp 192.168.1.0 0.0.0.255 any eq 443
This permits TCP traffic sourced from the 192.168.1.0/24 network, destined to any address, specifically on destination port 443 (HTTPS).
Established keyword (a specific, commonly tested extended ACL feature):
access-list 115 permit tcp any established
The established keyword matches TCP traffic that is part of an already-established session — specifically, TCP segments with the ACK or RST flag set — allowing return traffic for connections that were originally initiated from the inside network, without needing to explicitly permit all inbound traffic on every possible port. This is commonly used on an ACL applied inbound on an outside-facing interface, allowing replies to internally-initiated sessions back in, while still blocking unsolicited inbound connection attempts (which would arrive with only the SYN flag set, not matching established).
Exam Alert: The established keyword is a frequently tested detail — know that it matches based on the ACK/RST flags being set (indicating an already-established session, not a new incoming connection attempt), making it a simple (though less sophisticated than a true stateful firewall) way to allow return traffic while still blocking new unsolicited inbound sessions.
Missing the implicit deny's consequences — forgetting that every ACL ends with an implicit deny all, and failing to include a permit statement for legitimate traffic, results in that traffic being silently blocked.
Statement order producing unintended results — since processing stops at the first match, a broader, more general statement placed before a more specific one can prevent the more specific statement from ever actually being evaluated, even though it's correctly configured further down the list.
Standard ACL applied where destination/port-based filtering was actually needed — since standard ACLs can only match source address, attempting to use one where destination or protocol/port-specific filtering is required will simply fail to accomplish the intended goal.
Wrong direction (in vs. out) applied on the interface — an ACL correctly written but applied in the wrong direction relative to the intended traffic flow will not produce the intended filtering effect.
ACL applied to the wrong interface entirely — particularly relevant on a router with multiple interfaces, where the ACL's source/destination criteria assume a specific interface's perspective that doesn't match where it was actually applied.
Accidentally locking out remote management access — an ACL applied to an interface (or to the VTY lines directly) that doesn't account for the administrator's own management traffic can immediately cut off remote SSH/Telnet access to the device, a classic, severe real-world (and exam) mistake.
Exam Alert: Expect a scenario showing a specific ACL and its interface application, asking whether a particular type of traffic (from a particular source, to a particular destination, on a particular port) would be permitted or denied — carefully trace through the ACL top-down, remembering first-match-wins and the final implicit deny.
show access-lists (or show ip access-lists) — displays every configured ACL, its individual statements, and (very usefully during troubleshooting) a running match counter next to each statement showing how many times that specific line has actually matched traffic
show ip interface [interface] — shows which ACL(s), if any, are currently applied to that specific interface, and in which direction
show running-config — displays the full ACL configuration exactly as entered, including named ACLs and their submode statements
Exam Alert: The per-statement match counters shown in show access-lists output are a very practical troubleshooting tool — a statement with zero matches when traffic was expected to hit it often reveals that an earlier, broader statement is actually catching that traffic first, due to the first-match-wins processing rule.
Determine whether the filtering requirement needs only source-address matching (standard ACL) or more granular destination/protocol/port matching (extended ACL).
Decide on numbered versus named based on organizational preference — named ACLs are generally preferred for their descriptive clarity and easier line-by-line editing.
Write the ACL statements in the correct logical order, remembering that more specific statements generally need to come before broader ones that would otherwise match first and prevent the specific statement from ever being evaluated.
Always include an explicit permit statement for legitimate traffic, remembering the implicit deny all at the end of every ACL.
Apply the ACL to the correct interface, in the correct direction (in or out, evaluated from the router's own perspective for that specific interface) — standard ACLs generally placed close to the destination, extended ACLs generally placed close to the source.
Before applying an ACL to a live production interface (especially involving remote management access), carefully confirm the administrator's own management traffic is accounted for, to avoid an accidental lockout.
Verify actual behavior using show access-lists to review per-statement match counters, confirming traffic is matching the statement you expect it to, rather than an earlier, broader statement catching it first.
Q1. Which number range is used for standard numbered ACLs?
A. 100–199
B. 1–99
C. 2000–2699
D. 1300–1999 only, never 1–99
Answer: B. Standard numbered ACLs use the range 1–99 (with an expanded range of 1300–1999 also available). Extended numbered ACLs use the range 100–199 (with an expanded range of 2000–2699).
Q2. An administrator configures an ACL consisting only of a single statement: deny 192.168.5.10 0.0.0.0. No other statements are added. What happens to all other traffic not matching this specific statement?
A. All other traffic is automatically permitted
B. All other traffic is denied, due to the implicit deny at the end of every ACL
C. The ACL will fail to apply without an explicit permit statement
D. Only traffic from 192.168.5.0/24 is affected
Answer: B. Every ACL ends with an implicit deny all, even though it's never displayed in the configuration. Since this ACL contains only a single deny statement and no explicit permit statement for any other traffic, all traffic that doesn't match the specific deny statement falls through to the implicit deny and is blocked entirely.
Q3. Why is it generally recommended to place a standard ACL as close to the destination as possible, rather than close to the source?
A. Standard ACLs process traffic faster when placed near the destination
B. Standard ACLs can only match on source address, so placing them too close to the source risks unintentionally blocking traffic meant for other legitimate destinations
C. Standard ACLs require a destination address to function at all
D. Placement has no effect on standard ACL behavior
Answer: B. Since a standard ACL can only filter based on source IP address (with no ability to distinguish between different destinations), placing it too close to the source risks blocking that source's traffic entirely, even for destinations that traffic should have been allowed to reach. Placing it closer to the destination allows more precise control, filtering only right before the traffic reaches the specific destination actually intended to be restricted.
Q4. Which extended ACL keyword allows return traffic for TCP sessions that were originally initiated from the inside network, by matching packets with the ACK or RST flag set?
A. eq
B. range
C. established
D. host
Answer: C. The established keyword matches TCP segments that have the ACK or RST flag set, indicating they're part of an already-active session rather than a new incoming connection attempt (which would only have the SYN flag set). This allows an ACL to permit return traffic for internally-initiated sessions while still blocking unsolicited new inbound connections.
Q5. An ACL is applied with the command "ip access-group 110 out" on GigabitEthernet0/1. What does this configuration actually filter?
A. Traffic entering the router through GigabitEthernet0/1
B. Traffic leaving the router through GigabitEthernet0/1, after the routing decision has already been made
C. Traffic sourced from GigabitEthernet0/1's own IP address only
D. All traffic on the router regardless of interface
Answer: B. The out direction filters traffic as it is about to exit the router through that specific interface, evaluated after the router has already made its routing decision to send the packet out through GigabitEthernet0/1. This is distinct from in, which filters traffic as it enters the router through that interface, before any routing decision occurs.
Q6. What is a key practical advantage of a named ACL over a numbered ACL?
A. Named ACLs can match on destination address while numbered ACLs cannot
B. Named ACLs provide descriptive naming and allow individual statements to be more naturally inserted or removed using sequence numbers
C. Named ACLs do not have an implicit deny at the end
D. Named ACLs can only be applied to VTY lines, not physical interfaces
Answer: B. Named ACLs allow an administrator to assign a clear, descriptive name reflecting the ACL's actual purpose, rather than relying on an arbitrary number, and their dedicated configuration submode naturally supports inserting, removing, or reordering individual statements using sequence numbers without needing to delete and completely rebuild the entire ACL.