NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Lab Objectives

Configure numbered and named standard ACLs to filter traffic by source IP.
Apply ACLs to interfaces using ip access-group in the correct direction.
Verify ACL behavior and interpret command output to confirm correct placement.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Create and apply a numbered standard ACL

Create a numbered standard ACL (number 10) that permits the Sales network (192.168.1.0/24) and denies all other sources. Apply this ACL outbound on R1 GigabitEthernet0/0 (the link toward the Internet 203.0.113.1) so only Sales hosts are allowed to reach the Internet.

Task 2: Create and apply a named standard ACL

Create a named standard ACL called ENG_ONLY that permits the Engineering network (192.168.2.0/24) and denies all others. Apply this ACL inbound on R2 GigabitEthernet0/0 (the link toward R1) so only Engineering hosts are allowed to traverse toward R1.

Task 3: Replace numbered ACL with an equivalent named ACL

On R1, remove the numbered ACL 10 and replace it with a named ACL called SALES_OUTBOUND that has the same effect (permit 192.168.1.0/24; deny others) and re-apply outbound on Gi0/0.

Think About It: Why do you apply the ACL closest to the traffic’s destination in Task 1 (outbound toward the Internet) but apply the ACL closest to the traffic’s source in other scenarios? How does direction and placement affect what traffic is filtered and where filtering is most efficient?

Lab Solution

ASCII Topology (base lab topology — exact router interface IPs shown)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
           Gi0/0: 10.10.10.1
           Gi0/1: 10.10.20.1
           Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 Gi0/0: 10.10.20.2 Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | | / \ | | S1 S2 S3 ... / \ | /
PC1 PC2 PC3 PC4 PC5

IP subnets:

R1–R2: 10.10.10.0/24 (R1 Gi0/0 = 10.10.10.1, R2 Gi0/0 = 10.10.10.2)
R1–R3: 10.10.20.0/24 (R1 Gi0/1 = 10.10.20.1, R3 Gi0/0 = 10.10.20.2)
R1–R4: 10.10.30.0/24 (R1 Gi0/2 = 10.10.30.1, R4 Gi0/0 = 10.10.30.2)
R2–S1: 10.10.40.0/24 (R2 Gi0/1 = 10.10.40.1)
VLAN 10 (Sales): 192.168.1.0/24
VLAN 20 (Engineering): 192.168.2.0/24
VLAN 30 (Management): 192.168.3.0/24

Tip: Standard ACLs filter only by source address. Use them when your policy depends solely on where traffic originates.

Task 1 Solution: Create and apply a numbered standard ACL

What we are doing: Permit only the Sales network (192.168.1.0/24) to reach the Internet. Apply the ACL on R1 Gi0/0 outbound (closest to destination — the Internet) so it filters traffic before it leaves toward 203.0.113.1.

R1# configure terminal
R1(config)# access-list 10 permit 192.168.1.0 0.0.0.255
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group 10 out
R1(config-if)# end

What each command does and why it matters:

access-list 10 permit 192.168.1.0 0.0.0.255 — creates a numbered standard ACL (10) permitting source addresses in 192.168.1.0/24. Standard ACL numbers 1–99 are used on many IOS versions; the wildcard mask 0.0.0.255 matches the whole /24. This defines the policy.
interface GigabitEthernet0/0 — moves to the R1 interface that faces the Internet. We will bind the ACL here.
ip access-group 10 out — applies ACL 10 to packets leaving the interface (outbound). Direction matters: outbound means we inspect packets as they exit toward the Internet and filter by source IP.
end — exits configuration mode.

Verify:

R1# show access-lists
Standard IP access list 10
    10 permit 192.168.1.0 0.0.0.255

R1# show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 ip access-group 10 out
!

Why the verification matters: show access-lists confirms the ACL exists and the permit statement is present. show running-config interface ... confirms the ACL is applied in the intended direction on the correct interface.

Task 2 Solution: Create and apply a named standard ACL

What we are doing: Define a named standard ACL (ENG_ONLY) to permit only Engineering (192.168.2.0/24). Named ACLs are easier to read and extend than numbered ACLs.

R2# configure terminal
R2(config)# ip access-list standard ENG_ONLY
R2(config-std-nacl)# permit 192.168.2.0 0.0.0.255
R2(config-std-nacl)# exit
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip access-group ENG_ONLY in
R2(config-if)# end

What each command does and why it matters:

ip access-list standard ENG_ONLY — creates a named standard ACL context called ENG_ONLY. Named ACLs allow descriptive names and line-numbered entries.
permit 192.168.2.0 0.0.0.255 — adds a permit entry for the Engineering subnet. All other sources are implicitly denied.
interface GigabitEthernet0/0 and ip access-group ENG_ONLY in — bind the named ACL to R2’s interface facing R1, checking packets as they arrive from R1 (inbound). Applying inbound here restricts which source networks can be received from R1 toward R2’s internal networks.

Verify:

R2# show ip access-lists
Standard IP access list ENG_ONLY
    10 permit 192.168.2.0 0.0.0.255

R2# show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 10.10.10.2 255.255.255.0
 ip access-group ENG_ONLY in
!

Why the verification matters: show ip access-lists shows the named ACL and its statements; show running-config interface confirms the ACL is applied inbound on the correct interface.

Task 3 Solution: Replace numbered ACL with named ACL on R1

What we are doing: Remove ACL 10 and replace it with a more descriptive named ACL SALES_OUTBOUND, then re-apply outbound on Gi0/0.

R1# configure terminal
R1(config)# no access-list 10
R1(config)# ip access-list standard SALES_OUTBOUND
R1(config-std-nacl)# permit 192.168.1.0 0.0.0.255
R1(config-std-nacl)# exit
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip access-group SALES_OUTBOUND out
R1(config-if)# end

What each command does and why it matters:

no access-list 10 — removes the old numbered ACL. This clears the policy so we can replace it cleanly.
ip access-list standard SALES_OUTBOUND & permit ... — create the named ACL equivalent, improving clarity and maintainability.
ip access-group SALES_OUTBOUND out — re-applies the named ACL outbound so the traffic-matching behavior remains identical.

Verify:

R1# show ip access-lists
Standard IP access list SALES_OUTBOUND
    10 permit 192.168.1.0 0.0.0.255

R1# show running-config interface GigabitEthernet0/0
interface GigabitEthernet0/0
 ip address 10.10.10.1 255.255.255.0
 ip access-group SALES_OUTBOUND out
!

Troubleshooting Scenario

Scenario: ACL blocks intended traffic

Symptom: Ping from a Sales host (192.168.1.10) to Internet address 203.0.113.1 fails even though Sales should be permitted.

Your task: Find and fix the issue.

Hint: Check ACL direction and whether an older ACL still exists.

Solution:

Show the interface config and ACLs:

R1# show running-config interface GigabitEthernet0/0
R1# show ip access-lists

If the ACL is applied in instead of out, change to the correct direction:

R1(config)# interface GigabitEthernet0/0
R1(config-if)# no ip access-group SALES_OUTBOUND in
R1(config-if)# ip access-group SALES_OUTBOUND out

If an old numbered ACL remains, remove it:

R1(config)# no access-list 10

Explanation: Applying a standard ACL in the wrong direction can block traffic you intended to permit. Also leftover ACLs with deny entries could still be applied.

Verification Checklist

ACLs exist with the intended permit statements (show ip access-lists).
ACLs are applied to the correct interface in the correct direction (show running-config interface ...).
Test pings from representative hosts to confirm permitted/denied behavior.

Common Mistakes

Symptom	Cause	Fix
Sales still cannot reach Internet	ACL applied inbound on Gi0/0 instead of outbound	Remove `ip access-group ... in`; apply `ip access-group ... out` on R1 Gi0/0
No change after ACL modification	Old ACL still applied or not removed	`no access-list <number>` or remove old `ip access-group` then reapply new ACL
Unexpected hosts blocked	Used subnet wildcard mask incorrectly (e.g., wrong wildcard)	Correct wildcard mask: for /24 use `0.0.0.255`

Warning: Standard ACLs match only by source IP. If you need to filter by destination or by protocol/port, use extended ACLs instead.

Challenge Task

Create a single named standard ACL on R1 called HYBRID_POLICY that permits both Sales (192.168.1.0/24) and Engineering (192.168.2.0/24), denies Management (192.168.3.0/24), and implicitly denies all others. Apply it where it best limits unnecessary traffic toward the Internet. Verify the policy with show commands and explain your choice of ACL placement.

Standard ACL Configuration

Lab Objectives

Lab Tasks (Try It Yourself First!)

Task 1: Create and apply a numbered standard ACL

Task 2: Create and apply a named standard ACL

Task 3: Replace numbered ACL with an equivalent named ACL

Lab Solution

Task 1 Solution: Create and apply a numbered standard ACL

Task 2 Solution: Create and apply a named standard ACL

Task 3 Solution: Replace numbered ACL with named ACL on R1

Troubleshooting Scenario

Scenario: ACL blocks intended traffic

Verification Checklist

Common Mistakes

Challenge Task