Hands-On Lab: Configuring Named ACLs

This hands-on lab configures a named extended ACL, demonstrating how a descriptive name replaces a numeric identifier and how individual entries can be edited by sequence number without recreating the entire list.

Named ACL ConfigurationSequence Number EditingACL Readability

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure a named extended ACL, verify it functions identically to a numbered ACL, and edit a single entry using its sequence number without removing and reapplying the entire list.

Lab Purpose

Named ACLs, discussed earlier in this series, are generally preferred over numbered ACLs in modern configurations because the name documents the ACL's purpose directly, and individual entries can be inserted, removed, or edited by sequence number, avoiding the need to delete and rebuild the entire list for a small change.

Lab Topology

R1
  Gi0/0: 192.168.35.1/24 (internal LAN)
  Gi0/1: 203.0.113.5/30 (WAN, toward internet)

Task 1: Configure Basic Addressing

Configure both interfaces as shown.

Task 2: Create a Named Extended ACL

Create a named ACL called WEB-ONLY, permitting HTTP and HTTPS traffic from the internal LAN, with an explicit deny for everything else.

Task 3: Apply the ACL

Apply WEB-ONLY inbound on Gi0/0.

Task 4: Verify the Sequence Numbers

Display the ACL and note the automatically assigned sequence numbers for each entry.

Task 5: Insert a New Entry Using a Specific Sequence Number

Insert a new permit statement for DNS traffic (port 53) between the two existing entries, using a sequence number that places it correctly, without deleting and recreating the ACL.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.35.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# exit
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 203.0.113.5 255.255.255.252
R1(config-if)# no shutdown

R1(config)# ip access-list extended WEB-ONLY
R1(config-ext-nacl)# permit tcp 192.168.35.0 0.0.0.255 any eq 80
R1(config-ext-nacl)# permit tcp 192.168.35.0 0.0.0.255 any eq 443
R1(config-ext-nacl)# deny ip any any

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip access-group WEB-ONLY in

R1# show ip access-lists WEB-ONLY

Extended IP access list WEB-ONLY
    10 permit tcp 192.168.35.0 0.0.0.255 any eq www
    20 permit tcp 192.168.35.0 0.0.0.255 any eq 443
    30 deny ip any any
-- IOS automatically assigned sequence numbers
-- in increments of 10, leaving room to
-- insert new entries between existing ones

R1(config)# ip access-list extended WEB-ONLY
R1(config-ext-nacl)# 15 permit udp 192.168.35.0 0.0.0.255 any eq 53

-- Using sequence number 15 places this new
-- entry precisely between the existing 10
-- and 20, without touching either of them
-- or the deny statement at 30

R1# show ip access-lists WEB-ONLY

Extended IP access list WEB-ONLY
    10 permit tcp 192.168.35.0 0.0.0.255 any eq www
    15 permit udp 192.168.35.0 0.0.0.255 any eq 53
    20 permit tcp 192.168.35.0 0.0.0.255 any eq 443
    30 deny ip any any

Key Takeaway

The gap left between automatically assigned sequence numbers (typically increments of 10) exists specifically to allow inserting new entries later without renumbering or recreating the entire ACL — this is a significant practical advantage over the numbered ACL syntax used in earlier labs, which requires removing and re-adding the complete list to make even a single small change.

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

مقالات مرتبط

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.

ادامه