Access control lists (ACLs) are the network engineer's first line of defense — and the CCNA 200-301 exam expects you to master them. Standard ACLs are the simplest form, filtering traffic based solely on source IP address. While basic, they appear in exam scenarios, real-world access policies, and as building blocks for more advanced features. This chapter covers exam objective 5.6: Configure, verify, and troubleshoot standard IPv4 ACLs.
Jump to a section
Imagine a nightclub with a single entrance. The bouncer (the router) has a clipboard with a list of names (the ACL). Each name on the list is either 'allowed' or 'denied' entry. When a person (a packet) arrives, the bouncer checks their ID (source IP address) against the list, starting from the top. The first match wins: if the name is on the allowed list, they enter; if on the denied list, they are turned away. If their name isn't on the list at all, the bouncer has a default rule: 'If no match, deny entry' — that's the implicit deny at the end of every ACL. The bouncer cannot check anything else about the person — not their age, not what they're carrying, not where they're going — only their name. That's why standard ACLs are placed close to the destination: they only look at source IP, so placing them near the source could block traffic that should be allowed, because the filter can't distinguish between traffic to different destinations. Also, the list is processed top-down, so order matters: if 'deny Bob' appears before 'allow Bob', Bob is denied even though an allow rule exists later. The bouncer never rechecks the list after a match. This mechanistic analogy mirrors how a standard ACL works: sequential matching, first-match wins, implicit deny, and source-only filtering.
What is a Standard ACL?
A standard access control list (ACL) is a sequential list of permit or deny statements that apply to packet source IP addresses. On Cisco IOS, standard ACLs are numbered 1-99 or 1300-1999 (expanded range). They are the simplest form of traffic filter because they examine only the source IP address — not the destination, protocol, or port. The router checks each packet against the ACL entries in order, and the first matching entry determines the action (permit or deny). If no entry matches, the packet is denied by the implicit deny any rule at the end.
Standard ACLs are typically applied close to the destination network. Why? Because they filter only on source IP, placing them near the source could block all traffic from that source, regardless of destination. For example, if you want to block host A from reaching server B but allow host A to reach server C, a standard ACL placed at the source router would block host A from both servers. By placing it near the destination (server B's router), you filter only the traffic destined to that network.
How Standard ACLs Work Step by Step
When a packet enters an interface with an inbound ACL, or exits an interface with an outbound ACL, the router performs the following steps:
Extract the source IP address from the packet header.
Start at the top of the ACL (lowest sequence number).
Compare the source IP address to the wildcard mask of the current entry.
If the IP address falls within the range defined by the wildcard mask, the match is made, and the associated permit or deny action is executed. The packet is either forwarded (permit) or dropped (deny).
If no match, move to the next entry.
If all entries are checked and no match is found, the packet is denied (implicit deny any).
Key point: The router stops processing the ACL as soon as a match is found. This makes the order of entries critical. A common mistake is placing a broad permit statement before a more specific deny, which causes the deny to never be evaluated.
Wildcard Masks: The Inverse of Subnet Masks
Standard ACLs use wildcard masks to define which bits of the source IP address must match exactly (0) and which bits can be anything (1). A wildcard mask is 32 bits long, where: - 0 means the corresponding bit in the address must match. - 1 means the corresponding bit is ignored (don't care).
For example, wildcard mask 0.0.0.0 means all 32 bits must match — this matches a single host. Wildcard mask 255.255.255.255 means all bits are ignored — this matches any IP address (equivalent to 'any').
To match a subnet, you take the subnet mask and invert it. For example, subnet mask 255.255.255.0 (/24) becomes wildcard mask 0.0.0.255. So an ACL entry like:
access-list 10 permit 192.168.1.0 0.0.0.255matches any source IP from 192.168.1.0 to 192.168.1.255.
Common wildcard masks: - /30: 0.0.0.3 - /29: 0.0.0.7 - /28: 0.0.0.15 - /24: 0.0.0.255 - /16: 0.0.255.255 - /8: 0.255.255.255 - /0: 255.255.255.255 (any)
Implicit Deny Any
Every ACL has an invisible final entry: deny any (or deny ip any any). This means if a packet does not match any explicit permit or deny statement, it is dropped. Therefore, you must have at least one permit statement in an ACL if you want any traffic to pass. Many candidates forget this and create an ACL with only deny statements, wondering why all traffic is blocked.
Applying ACLs to Interfaces
ACLs are applied to interfaces using the ip access-group command. The direction can be in or out:
Inbound ACL: Filters packets before they are routed. The router checks the ACL when the packet arrives on the interface, before making a routing decision.
Outbound ACL: Filters packets after they are routed. The router checks the ACL before sending the packet out the interface.
Standard ACLs are most commonly applied outbound, close to the destination, because they filter only on source IP.
Configuring a Standard ACL
Configuration steps:
1. Create the ACL with global configuration command access-list <number> {permit | deny} <source> [wildcard].
2. Apply the ACL to an interface with ip access-group <number> {in | out}.
Example: Permit host 10.1.1.1 to access network 192.168.1.0/24, deny all others.
R1(config)# access-list 10 permit host 10.1.1.1
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip access-group 10 outNote: host 10.1.1.1 is shorthand for 10.1.1.1 0.0.0.0.
Verifying Standard ACLs
Use show access-lists to display all ACLs and their hit counts. Example output:
R1# show access-lists
Standard IP access list 10
10 permit 10.1.1.1 (5 matches)The number 10 on the left is the sequence number (automatically assigned, can be modified in named ACLs). The (5 matches) shows how many packets have matched that entry.
Use show ip interface <interface> to verify which ACL is applied and in which direction:
R1# show ip interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
Internet address is 192.168.1.1/24
...
Outgoing access list is 10
Inbound access list is not setTroubleshooting Standard ACLs
Common issues:
No permit statement: All traffic denied.
Wrong order: A permit statement placed after a deny that matches the same traffic.
Wrong wildcard mask: Too broad or too narrow.
Applied to wrong interface or wrong direction.
Missing ip access-group command.
Use show access-lists to see hit counts. If an entry never increments, either the traffic is not matching (check wildcard) or a previous entry is matching first.
Interaction with Other Features
Standard ACLs can be used not only for traffic filtering but also for:
Route filtering (with distribute-list)
Controlling Telnet/SSH access (with access-class)
VPN policy (crypto maps)
QoS classification
However, on the CCNA, the focus is on traffic filtering and basic configuration.
Plan the ACL placement and direction
Decide which traffic you want to filter. Since standard ACLs check only source IP, place the ACL as close to the destination as possible. For example, to block host 10.1.1.1 from accessing network 192.168.1.0/24, apply the ACL outbound on the router interface facing that network. Determine the direction: inbound filters traffic entering the interface; outbound filters traffic leaving the interface. For standard ACLs, outbound is typical.
Create the ACL with permit/deny entries
Use global config command `access-list <number> {permit | deny} <source> [wildcard]`. Number must be 1-99 or 1300-1999 for standard ACLs. Wildcard mask defaults to 0.0.0.0 (host match) if omitted. Use `host` keyword for single IP. Use `any` for all IPs. Order matters: more specific entries first. Example: ``` access-list 10 deny host 10.1.1.1 access-list 10 permit 192.168.1.0 0.0.0.255 ``` This denies a specific host but permits the whole subnet.
Apply the ACL to an interface
Enter interface configuration mode and use `ip access-group <number> {in | out}`. Example: ``` interface GigabitEthernet0/1 ip access-group 10 out ``` This applies ACL 10 to outgoing traffic on G0/1. Verify with `show ip interface G0/1`.
Verify ACL operation with show commands
Use `show access-lists` to see the ACL entries and match counts. Example output: ``` R1# show access-lists Standard IP access list 10 10 deny 10.1.1.1 (2 matches) 20 permit 192.168.1.0, wildcard bits 0.0.0.255 (15 matches) ``` If match counts are zero for an entry, traffic is not matching that rule. Check wildcard mask and order.
Test connectivity from permitted/denied hosts
Use ping or traceroute from source hosts to verify the ACL is working as intended. For a denied host, ping should fail. For permitted hosts, ping should succeed. If unexpected results occur, check the ACL configuration, interface application, and routing. Remember: the implicit deny at the end blocks all traffic not explicitly permitted.
Edit or remove ACL as needed
To remove an ACL, use `no access-list <number>`. To remove an ACL from an interface, use `no ip access-group <number> {in | out}`. To edit a numbered ACL, you must remove and recreate it because numbered ACLs do not allow inserting or deleting individual entries. For named ACLs, you can edit with sequence numbers. Example: ``` R1(config)# no access-list 10 R1(config)# access-list 10 permit 10.1.1.0 0.0.0.255 ```
In enterprise networks, standard ACLs are often used for simple source-based filtering. One common scenario is restricting management access to network devices. For example, a network engineer may create a standard ACL that permits only the IT department's subnet (e.g., 10.10.10.0/24) to SSH into routers and switches. The ACL is applied to the VTY lines using the access-class command:
access-list 5 permit 10.10.10.0 0.0.0.255
line vty 0 15
access-class 5 inThis ensures only users from the IT subnet can remotely manage the device, blocking brute-force attacks from other sources.
Another scenario is segmenting guest and corporate networks. Suppose a company has a guest Wi-Fi subnet (172.16.0.0/16) that should only access the internet, not internal resources. A standard ACL on the router interface facing the internal network can deny traffic from the guest subnet:
access-list 15 deny 172.16.0.0 0.0.255.255
access-list 15 permit any
interface GigabitEthernet0/1
ip access-group 15 outThis blocks guest traffic from entering the internal network while allowing all other traffic (including return traffic from internal to guest) because ACLs filter only one direction. However, since standard ACLs filter only source IP, they cannot distinguish between different destinations within the internal network. If the requirement is to allow guest access to a specific server, an extended ACL would be needed.
Performance-wise, standard ACLs are lightweight because they only check source IP. On high-throughput links, ACL processing can introduce latency, but standard ACLs have minimal impact. A common pitfall is misplacing the ACL (e.g., applying inbound near the source), which can block legitimate traffic. For example, applying an ACL that denies a host on the source router's inbound interface would block that host from reaching any destination, not just the intended one.
When misconfigured, the most common symptom is complete loss of connectivity for a subset of users. Troubleshooting involves checking show access-lists for match counts and verifying the interface direction. Many engineers forget the implicit deny and wonder why an ACL with only deny statements blocks everything. Always include a permit any at the end if you want to allow other traffic.
In production, ACLs should be carefully documented and version-controlled. A change to an ACL can have widespread impact. Best practice is to use named ACLs (e.g., ip access-list standard MANAGEMENT) for easier editing and readability, though the CCNA exam focuses on numbered ACLs.
The CCNA 200-301 exam objective 5.6 expects you to configure, verify, and troubleshoot standard IPv4 ACLs. The exam will test your ability to:
Choose the correct ACL number (1-99 or 1300-1999) for standard ACLs.
Write ACL entries with proper wildcard masks.
Apply ACLs to interfaces with the correct direction.
Predict the effect of an ACL on traffic flow.
Identify misconfigurations such as wrong order, wrong wildcard, or missing permit.
Common wrong answers and why candidates choose them:
Confusing wildcard mask with subnet mask. Many candidates write access-list 10 permit 192.168.1.0 255.255.255.0 instead of 0.0.0.255. Remember: wildcard is the inverse of subnet mask. If the subnet mask is /24 (255.255.255.0), the wildcard is 0.0.0.255.
Placing a deny any before a permit statement. Candidates think they need to explicitly deny all traffic, then permit specific traffic. But because ACLs are processed top-down and first match wins, a deny any at the top will block everything, making subsequent permits useless. The correct approach is to permit specific traffic first, then let the implicit deny handle the rest.
Applying ACL inbound instead of outbound. Standard ACLs filter only source IP. If applied inbound near the source, they block all traffic from that source regardless of destination. The exam may present a scenario where a specific destination should be restricted; the correct answer is to apply the ACL outbound on the interface facing that destination.
Forgetting the implicit deny. Candidates often create an ACL with only deny statements and think traffic will be permitted by default. They forget that the implicit deny at the end blocks everything that doesn't match a permit. Always include a permit statement if you want any traffic to pass.
Using the wrong ACL number for extended ACLs. Standard ACLs use 1-99 and 1300-1999. Extended ACLs use 100-199 and 2000-2699. The exam may list ACL numbers without specifying type; you must know the ranges.
Decision rule for scenario questions: First, identify the traffic to filter (source only for standard). Second, determine the direction (outbound on the destination router's interface is typical). Third, write the ACL with specific entries first, then a permit any if needed. Finally, apply to the correct interface.
Memorize the wildcard mask for common prefixes: /24 -> 0.0.0.255, /16 -> 0.0.255.255, /8 -> 0.255.255.255. Also remember that host is shorthand for 0.0.0.0 wildcard, and any is shorthand for 255.255.255.255 wildcard.
Standard ACLs filter traffic based solely on source IP address.
Standard ACL numbers are 1-99 and 1300-1999.
Wildcard mask is the inverse of subnet mask; 0 = match, 1 = ignore.
ACLs are processed top-down; first match wins.
Implicit deny any at the end of every ACL.
Apply standard ACLs close to the destination, typically outbound.
Use `show access-lists` to verify ACL entries and match counts.
These come up on the exam all the time. Here's how to tell them apart.
Standard ACL
Filters on source IP only
Number range: 1-99, 1300-1999
Place close to destination
Simpler configuration
Less granular control
Extended ACL
Filters on source IP, destination IP, protocol, and port
Number range: 100-199, 2000-2699
Place close to source
More complex configuration
More granular control
Mistake
Standard ACLs can filter on destination IP and port numbers.
Correct
Standard ACLs only filter on source IP. To filter on destination or ports, you need an extended ACL (numbers 100-199 or 2000-2699).
Candidates often confuse standard and extended ACL capabilities because both are called ACLs.
Mistake
The wildcard mask 0.0.0.0 matches any IP address.
Correct
Wildcard mask 0.0.0.0 means all bits must match, so it matches only the exact IP address specified. Use `any` (wildcard 255.255.255.255) to match all addresses.
The zeros in the mask look like they mean 'no restriction' but actually mean 'must match exactly'.
Mistake
ACLs are applied inbound by default.
Correct
ACLs are not applied by default; you must explicitly apply them with `ip access-group` command, specifying either `in` or `out`. There is no default direction.
Candidates might assume ACLs are applied inbound because many examples use inbound ACLs.
Mistake
The order of entries in an ACL does not matter because the router checks all entries.
Correct
Order is critical. The router stops at the first match. If a deny entry appears before a permit entry that would also match, the packet is denied.
Candidates think the router evaluates all entries and picks the best match, like a routing table, but ACLs use first-match logic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The implicit deny is an invisible final entry in every ACL that denies any packet that does not match any explicit permit or deny statement. It is equivalent to `deny any` or `deny ip any any`. This means if you create an ACL with only deny statements, all traffic will be denied. Always include at least one permit statement if you want any traffic to pass. On the exam, remember that the implicit deny exists even if not shown in `show access-lists`.
Subtract each octet of the subnet mask from 255. For example, subnet mask 255.255.255.0 becomes wildcard 0.0.0.255 (255-255=0, 255-255=0, 255-255=0, 255-0=255). For a /28 subnet mask 255.255.255.240, wildcard is 0.0.0.15 (255-240=15). Alternatively, remember that the wildcard mask has 0s where the subnet mask has 1s, and 1s where the subnet mask has 0s.
No. Standard ACLs only examine the source IP address. If you need to filter based on destination IP or ports, use an extended ACL (numbers 100-199 or 2000-2699). A common exam trap is presenting a scenario that requires destination filtering and offering a standard ACL as an option.
An inbound ACL filters packets as they enter the interface, before routing. An outbound ACL filters packets after routing, before they exit the interface. For standard ACLs, outbound application is typical because you place them close to the destination. Inbound ACLs are often used for security at the network edge.
Use the `no ip access-group <number> {in|out}` command in interface configuration mode. To delete the entire ACL, use `no access-list <number>` in global configuration mode. Note that removing the ACL from the interface does not delete the ACL itself; it just stops applying it.
The 'matches' counter shows the number of packets that have matched that specific ACL entry since the last counter reset (or router reload). It helps verify that traffic is hitting the intended rule. If a rule has zero matches, either the traffic is not reaching the ACL or a preceding rule is matching first.
No. Numbered ACLs do not support inserting or deleting individual entries. To modify a numbered ACL, you must remove it with `no access-list <number>` and recreate it with the desired entries. For easier editing, use named ACLs (e.g., `ip access-list standard NAME`) which allow adding and removing entries by sequence number.
You've just covered Standard ACLs — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?