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 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه