Access control lists (ACLs) are one of the most frequently tested topics on the CCNA 200-301 exam, and standard ACLs are the foundation. This lab walks you through configuring a standard ACL to filter traffic based on source IP address—a skill you'll use daily in real networks for security and traffic management. Mastering this lab ensures you can answer scenario-based questions on exam objective 5.6 (Configure and verify ACLs) with confidence.
Jump to a section
Imagine a nightclub with a strict entry policy. The bouncer (the router) stands at the door (the interface) and checks every person (packet) trying to enter. The bouncer has a list—the 'guest list'—that contains names (source IP addresses) of people who are allowed in. This is a standard ACL: it only looks at the person's name (source IP), not what they're wearing or carrying (destination IP, port, etc.). The bouncer has a simple rule: if the name is on the list, let them in; if not, deny entry. But the bouncer also has a 'block list'—people who are explicitly denied. In networking, standard ACLs are typically placed close to the destination network to filter traffic as it arrives. However, the bouncer analogy highlights a limitation: the bouncer doesn't know if a person is carrying a weapon (like a dangerous port) because they only check identity. That's why for finer control, you'd use an extended ACL (which checks ports and protocols). In the lab, you'll configure the bouncer's list on a router interface, specifying which source networks are allowed or denied. The bouncer (router) then applies that list to every packet entering or leaving the door (interface) in the specified direction.
What is a Standard ACL?
A standard Access Control List (ACL) is a sequential list of permit or deny statements that match packets based solely on the source IP address. Cisco IOS supports numbered standard ACLs (1–99 and 1300–1999) and named standard ACLs. Standard ACLs are simple but powerful for basic traffic filtering, such as preventing a specific subnet from accessing a network.
Why Use Standard ACLs?
Standard ACLs are used to filter traffic at Layer 3. Common uses include:
Blocking traffic from a specific host or subnet
Controlling which networks can access a server farm
Restricting management access to a router (via VTY ACLs)
Because they only examine source IP, they are less granular than extended ACLs. Cisco recommends placing standard ACLs as close to the destination as possible to avoid unintentionally blocking legitimate traffic (since you can't filter by destination).
How Standard ACLs Work
A standard ACL is a list of Access Control Entries (ACEs) processed in order. Each ACE has a sequence number, action (permit/deny), and source match condition (usually a wildcard mask). The router evaluates each packet against the list sequentially until a match occurs; then the specified action is taken. If no match is found, an implicit deny any at the end blocks the packet.
Wildcard masks are the inverse of subnet masks: 0 means 'must match exactly', 255 means 'ignore'. For example, 192.168.1.0 0.0.0.255 matches any address in the 192.168.1.0/24 subnet.
Configuration Steps
Create the ACL using the access-list command in global configuration mode.
Apply the ACL to an interface using ip access-group in interface configuration mode, specifying direction (in or out).
Example: Deny host 10.1.1.1, permit all others.
R1(config)# access-list 1 deny host 10.1.1.1
R1(config)# access-list 1 permit any
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group 1 inVerification Commands
show access-lists – displays all ACLs with match counts
show ip interface [interface] – shows which ACLs are applied
show running-config | include access-list – shows ACL configuration
Example output:
R1# show access-lists
Standard IP access list 1
10 deny 10.1.1.1 (4 matches)
20 permit any (10 matches)Note the sequence numbers (10, 20) automatically assigned. The match counts tell you how many packets hit each ACE.
Interaction with Routing
Standard ACLs filter traffic after the routing decision. For inbound ACLs, the packet is checked before being processed by the router; for outbound, after routing but before transmission. ACLs do not affect the router's own generated traffic (e.g., routing updates) unless explicitly filtered.
Limitations
Cannot filter by destination IP, protocol, or port.
Numbered standard ACLs cannot be edited; you must remove and recreate. Named ACLs allow insertion/deletion via sequence numbers.
Implicit deny any at the end – if you forget a permit statement, all traffic is blocked.
Best Practices
Use named ACLs for easier management.
Place standard ACLs close to the destination (to avoid blocking traffic that could be allowed by a different path).
Always include explicit permit statements for traffic you want to allow.
Use remark to document ACEs: access-list 1 remark Deny Bob's PC
Design the ACL Policy
Before configuring, decide what traffic to permit or deny. For this lab, we want to block host 10.1.1.1 from accessing the 192.168.1.0/24 network but allow everyone else. The ACL will be applied inbound on the router interface facing the 10.1.1.0/24 network (closest to the source). This is a standard ACL, so we match only source IP. We'll use ACL number 1. Write down the ACEs in order: deny host 10.1.1.1, permit any. Remember the implicit deny any at the end – we must include the permit any or all other traffic will be blocked.
Configure the ACL on R1
Enter global configuration mode on R1. Use `access-list 1 deny host 10.1.1.1` to create the first ACE. Then `access-list 1 permit any` to allow all other traffic. Cisco automatically assigns sequence numbers (starting at 10, incrementing by 10). You can also use `ip access-list standard 1` to enter named ACL config mode for more control, but for simplicity we use the legacy command. Verify with `show access-lists 1`. You should see two entries with match counters currently at 0.
Apply the ACL to the Interface
Identify the interface that receives traffic from the 10.1.1.0/24 network. In our topology, R1's GigabitEthernet0/0 connects to that subnet. Enter interface configuration mode: `interface GigabitEthernet0/0`. Apply the ACL inbound: `ip access-group 1 in`. This tells the router to evaluate all incoming packets on this interface against ACL 1. Verify with `show ip interface GigabitEthernet0/0` – look for 'Inbound access list is 1'.
Test the ACL from Host 10.1.1.1
From host 10.1.1.1, attempt to ping the destination host at 192.168.1.100. The ping should fail because the ACL denies source 10.1.1.1. To confirm, check the ACL match counters: `show access-lists 1`. The deny entry should show an increment in matches (e.g., '4 matches'). If it doesn't, verify the interface and direction. Also check that the host has a route to the destination; ACLs do not replace routing.
Test the ACL from a Permitted Host
From a different host in the 10.1.1.0/24 subnet (e.g., 10.1.1.2), ping the same destination. This should succeed. Check the ACL match counters again: the permit any entry should show matches. If the ping fails, ensure that the permit any entry is present and that there are no other ACLs applied. Also check that the destination network is reachable. This confirms that only the specific host is blocked.
Remove or Modify the ACL
To remove the ACL, first remove the interface application: `no ip access-group 1 in` under the interface. Then delete the ACL: `no access-list 1`. To modify a numbered ACL, you must remove and recreate it. For named ACLs, you can insert or delete individual ACEs using sequence numbers. In this lab, practice removing the ACL and reapplying it with a different rule, e.g., permit host 10.1.1.1 and deny all others. Always verify with `show access-lists` after changes.
In enterprise networks, standard ACLs are often used for basic segmentation. For example, a company might want to prevent the guest Wi-Fi subnet (192.168.100.0/24) from accessing the internal server network (10.10.10.0/24). A network engineer would configure a standard ACL on the router interface facing the guest subnet, denying source 192.168.100.0 0.0.0.255 and permitting all other traffic. This is simple and effective.
Another scenario is restricting management access. A standard ACL can be applied to the VTY lines of a router to allow only specific administrative hosts (e.g., 10.0.0.0/8) to SSH or Telnet into the device. Configuration: access-list 10 permit 10.0.0.0 0.255.255.255 and then line vty 0 4 with access-class 10 in. This is a common exam topic.
Performance-wise, standard ACLs are lightweight because they only check source IP. On modern routers, ACL processing is done in hardware (Cisco Express Forwarding) for line-rate filtering. However, misconfiguration can cause outages. For instance, placing a standard ACL too close to the source might block traffic that could take an alternate path to the destination. A classic mistake: applying a standard ACL outbound on an interface that connects to multiple subnets, inadvertently blocking traffic from unintended sources.
In production, always document ACLs with remarks and test changes during maintenance windows. Use show access-lists to monitor match counts and identify unused rules. Remember that standard ACLs cannot filter by destination, so for granular control (e.g., block only HTTP traffic), you need extended ACLs.
The CCNA 200-301 exam tests standard ACLs under objective 5.6: 'Configure and verify ACLs'. Expect scenario-based questions where you must choose the correct ACL configuration or identify a misconfiguration. Common traps:
Implicit deny any forgotten: Candidates often think that a single deny ACE is enough, but without a permit any, all traffic is blocked. The exam may show a config with only a deny statement and ask what happens.
Direction confusion: Applying an ACL in the wrong direction. For example, placing a standard ACL that blocks a source network on the outbound direction of the source's interface instead of inbound. Remember: standard ACLs should be placed close to the destination, but the direction is relative to the interface on which the traffic arrives or leaves.
Wildcard mask errors: Using a subnet mask instead of a wildcard mask. For example, access-list 1 deny 192.168.1.0 255.255.255.0 is wrong; it should be 0.0.0.255. The exam may disguise this.
Sequence number editing: For numbered ACLs, you cannot insert an ACE between existing ones. The exam might ask how to add a rule to the middle of a numbered ACL. Correct answer: remove and recreate the ACL. Named ACLs allow insertion.
VTY ACL using wrong command: Applying an ACL to VTY lines requires access-class, not ip access-group. Candidates sometimes use ip access-group on a VTY line, which is invalid.
Decision rule for scenario questions: Identify the traffic flow (source, destination, direction). Determine if the ACL is standard or extended. For standard, ensure only source IP is matched. Check for implicit deny. Verify the wildcard mask. Confirm the interface and direction match the problem statement.
Memorize: standard ACL numbers 1–99 and 1300–1999. The ip access-group command applies to interfaces; access-class applies to VTY lines. The show access-lists command displays match counts, which can help identify which ACE is being hit.
Standard ACLs filter based on source IP address only (Layer 3).
Numbered standard ACLs use ranges 1–99 and 1300–1999.
Wildcard mask uses 0 for exact match, 255 for ignore (inverse of subnet mask).
Implicit deny any exists at the end of every ACL – always include a permit statement if needed.
Apply standard ACLs close to the destination network.
Use `ip access-group` on interfaces, `access-class` on VTY lines.
Named ACLs allow insertion/deletion of individual entries via sequence numbers; numbered ACLs require removal and recreation.
These come up on the exam all the time. Here's how to tell them apart.
Standard ACL
Filters based on source IP only
Numbered ranges: 1–99, 1300–1999
Place close to destination
Simpler, fewer lines
Cannot filter by protocol or port
Extended ACL
Filters based on source/destination IP, protocol, port
Numbered ranges: 100–199, 2000–2699
Place close to source
More complex, more lines
Granular control (e.g., deny TCP from subnet to server)
Mistake
Standard ACLs can filter based on destination IP address.
Correct
Standard ACLs only examine the source IP address. For destination filtering, use extended ACLs.
Candidates confuse standard and extended ACL capabilities because both are called 'ACLs'.
Mistake
The wildcard mask for a /24 network is 255.255.255.0.
Correct
The correct wildcard mask for a /24 is 0.0.0.255. Wildcard masks are the inverse of subnet masks.
Candidates are used to subnet masks and forget to invert them for ACLs.
Mistake
Applying a standard ACL outbound on the source's interface is the best practice.
Correct
Cisco recommends placing standard ACLs as close to the destination as possible (inbound on the destination's interface) because they cannot filter by destination, so placing them near the source might block traffic that could reach the destination via another path.
Candidates think 'filter near the source' is always best, but for standard ACLs, it can cause unintended blocking.
Mistake
You can edit a numbered ACL by inserting a new entry at a specific sequence number.
Correct
Numbered ACLs do not support insertion; you must delete the entire ACL and recreate it. Named ACLs allow insertion using sequence numbers.
Candidates assume all ACLs are editable like named ACLs, but numbered ACLs are legacy and rigid.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A standard ACL filters traffic based only on the source IP address. An extended ACL can filter based on source and destination IP addresses, protocol (TCP, UDP, ICMP, etc.), and port numbers. Extended ACLs provide more granular control and are placed closer to the source, while standard ACLs are placed closer to the destination. For the CCNA exam, remember the number ranges: standard (1-99, 1300-1999) and extended (100-199, 2000-2699).
Numbered standard ACLs cannot be edited incrementally. To make changes, you must remove the entire ACL using `no access-list <number>` and then recreate it with the desired entries. If you need to edit, consider using a named ACL (`ip access-list standard <name>`) which allows you to insert or delete individual entries using sequence numbers. For the exam, know that numbered ACLs require deletion and recreation.
Every ACL has an implicit deny any statement at the end, meaning that if a packet does not match any ACE, it is denied. This is why you must include a `permit any` statement if you want to allow all traffic not explicitly denied. Many candidates forget this and wonder why all traffic is blocked after applying an ACL with only deny statements. Always verify with `show access-lists` to see the implicit deny (it is not displayed but is present).
Yes, but the command is different. Instead of `ip access-group`, you use `access-class` under the VTY line configuration. For example: `line vty 0 4` then `access-class 10 in`. The ACL itself is configured the same way. This is a common exam topic – remember that `access-class` is for VTY lines, `ip access-group` is for interfaces.
Several reasons: (1) The ACL might be applied in the wrong direction (e.g., outbound instead of inbound). (2) The source IP in the ACE might not match due to incorrect wildcard mask. (3) There might be another ACL on the same interface or another path that permits the traffic. (4) The host's traffic might be generated by the router itself (e.g., routing updates), which are not filtered by ACLs. Use `show access-lists` to check match counts – if the deny entry shows 0 matches, the packet is not being evaluated by that ACE.
For a /28 subnet (255.255.255.240), the wildcard mask is 0.0.0.15. The wildcard mask is the inverse of the subnet mask: subtract each octet from 255. So 255-255=0, 255-255=0, 255-255=0, 255-240=15. Common mistake: using 0.0.0.240, which would match only the first 28 bits exactly, but that's not how wildcards work. Practice converting subnet masks to wildcard masks.
Enter interface configuration mode and use `no ip access-group <acl-number> <in|out>`. For example: `interface GigabitEthernet0/0` then `no ip access-group 1 in`. This removes the ACL from the interface but does not delete the ACL itself. To delete the ACL, use `no access-list <number>` in global configuration mode. Always remove the interface application first to avoid unexpected behavior.
You've just covered Lab: Configure Standard ACL — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?