Hands-On Lab: Configuring Standard Numbered ACLs

This hands-on lab configures a standard numbered ACL to permit traffic from a specific subnet while denying everything else, applies it to the correct interface and direction, and verifies both permitted and denied traffic behave as expected.

Standard ACL ConfigurationACL PlacementImplicit Deny

~3 min read · Updated Sep 22, 2026

Lab Objective

Configure a standard numbered ACL permitting traffic only from a specific source subnet, apply it in the correct direction on the appropriate interface, and verify both permitted and blocked traffic behave as intended.

Lab Purpose

Standard ACLs, discussed earlier in this series, filter based only on source address, which directly determines where they must be placed to avoid unintentionally blocking legitimate traffic — this lab makes that placement rule concrete through hands-on practice.

Lab Topology

R1
  Gi0/0: 192.168.20.1/24 (HR subnet, should
                          be permitted)
  Gi0/1: 192.168.30.1/24 (Sales subnet, should
                          be denied)
  Gi0/2: 192.168.40.1/24 (destination server subnet)

Task 1: Configure Basic Addressing

Configure all three interfaces as shown.

Task 2: Create the Standard ACL

Create numbered ACL 10 permitting traffic from 192.168.20.0/24, with an implicit deny for everything else.

Task 3: Apply the ACL in the Correct Direction and Location

Apply the ACL outbound on Gi0/2, the interface closest to the destination, consistent with standard ACL placement best practice.

Task 4: Verify Permitted Traffic

Confirm a host on the HR subnet (192.168.20.0/24) can reach the server subnet.

Task 5: Verify Denied Traffic

Confirm a host on the Sales subnet (192.168.30.0/24) cannot reach the server subnet.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.20.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.30.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/2
R1(config-if)# ip address 192.168.40.1 255.255.255.0
R1(config-if)# no shutdown

R1(config)# access-list 10 permit 192.168.20.0 0.0.0.255

-- The implicit deny at the end of every ACL,
-- discussed earlier in this series, means no
-- additional deny statement is required --
-- everything not explicitly permitted is
-- already dropped by default

R1(config)# interface gigabitethernet0/2
R1(config-if)# ip access-group 10 out

HR-PC (192.168.20.10)> ping 192.168.40.10

Reply from 192.168.40.10: bytes=32 time=1ms
!!!!!
Success rate is 100 percent (5/5)

Sales-PC (192.168.30.10)> ping 192.168.40.10

Request timed out.
Request timed out.
Success rate is 0 percent (0/5)

R1# show access-lists

Standard IP access list 10
    10 permit 192.168.20.0, wildcard bits 0.0.0.255 (5 match(es))
-- The match counter confirms the permit
-- line is actually being hit by the HR
-- traffic that succeeded

Key Takeaway

Since a standard ACL can only match on source address, discussed earlier in this series, placing it too close to the source (such as on Gi0/0 or Gi0/1) would risk unintentionally blocking that traffic from reaching other legitimate destinations elsewhere in the network — applying it near the destination instead, as done here, ensures the filtering only affects traffic actually headed to that specific server subnet.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring VRRP

This hands-on lab configures VRRP between two routers as the open-standard alternative to HSRP, using a real interface address as the virtual IP, and verifies Master/Backup roles and automatic failover behavior.

Continue

Hands-On Lab: Configure GLBP Redundancy

This hands-on lab configures GLBP between two routers to achieve load balancing across both routers simultaneously, verifying that different hosts receive different virtual MAC addresses and therefore route through different physical gateways.

Continue

Hands-On Lab: Implementing HSRP

This hands-on lab configures HSRP between two routers sharing a virtual gateway address, sets priority and preempt to control which router is active, and verifies automatic failover when the active router fails.

Continue

Hands-On Lab: Verifying the EIGRP Database

This hands-on lab examines the EIGRP topology table directly, identifying the successor and feasible successor for a destination network, and demonstrates how this underlying data explains what appears in the IP routing table.

Continue

Hands-On Lab: Summarizing Routes with EIGRP

This hands-on lab manually configures interface-level route summarization in EIGRP, advertising a single aggregated route instead of several specific subnets, and verifies the automatically created Null0 discard route that prevents summarization-related loops.

Continue

Hands-On Lab: Passive Interfaces for EIGRP Updates

This hands-on lab configures a passive interface in EIGRP to stop routing updates from being sent out a LAN-facing interface while the network remains advertised, mirroring the same security and efficiency rationale covered earlier for OSPF passive interfaces.

Continue