16.2 Access Control Lists (ACLs) for Infrastructure Security

CCNP Enterprise ENCOR 350-401

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Enterprise Architecture & Hierarchical Design

1.1 Enterprise Network Design Models & Hierarchical Campus Architecture 1.2 On-Premises, Cloud & Hybrid Infrastructure Deployment Models 1.3 Hardware Switching Architecture & Packet Forwarding

2 Chapter 2: Enterprise Quality of Service (QoS)

2.1 QoS Components: Classification, Marking & Trust Boundaries 2.2 QoS Policy: Queuing, Shaping, Policing & Interpreting MQC Output

3 Chapter 3: Software-Defined WAN (Catalyst SD-WAN)

3.1 Cisco Catalyst SD-WAN Architecture & Orchestration 3.2 SD-WAN Policies, Traffic Engineering & Application-Aware Routing

4 Chapter 4: Software-Defined Access (Catalyst SD-Access)

4.1 Catalyst SD-Access Fabric Architecture & Plane Separation 4.2 Cisco TrustSec, Security Group Tags (SGT), SXP & MACsec

5 Chapter 5: Device & Data Path Virtualization

5.1 Server & Network Device Virtualization 5.2 VRF-Lite & Virtual Routing Multi-Tenancy 5.3 GRE & IPsec Tunnel Virtualization Mechanics

6 Chapter 6: Network Virtualization & Overlay Technologies

6.1 LISP Architecture & EID-to-RLOC Mapping Mechanics 6.2 VXLAN & EVPN Overlay Architecture

7 Chapter 7: Layer 2 Infrastructure & Switching

7.1 VLANs, 802.1Q Trunking & VTPv3 7.2 Spanning Tree Protocol Mechanics 7.3 Advanced STP Protection Mechanisms 7.4 EtherChannel Link Aggregation

8 Chapter 8: Layer 3 Routing Foundations & EIGRP

8.1 IP Routing Foundations & Administrative Distance 8.2 Enhanced Interior Gateway Routing Protocol (EIGRP)

9 Chapter 9: OSPFv2 & OSPFv3 Operations

9.1 OSPFv2 Architecture & Neighbor State Machine 9.2 OSPF LSA Types & Multi-Area Design 9.3 OSPFv3 for IPv4 and IPv6 Address Families

10 Chapter 10: Border Gateway Protocol (BGP)

10.1 BGP Architecture, Neighbor States & Peering 10.2 BGP Path Attributes & Best Path Selection Algorithm

11 Chapter 11: Policy-Based Routing & Route Redistribution

11.1 Policy-Based Routing (PBR) & Route Maps 11.2 Route Redistribution & Loop Prevention

12 Chapter 12: IP Services & High Availability

12.1 First Hop Redundancy Protocols (HSRP, VRRP & GLBP) 12.2 Network Time Protocol (NTPv4) & Precision Time Protocol (PTP) 12.3 Network Address Translation (NAT/PAT) & VRF-Aware NAT

13 Chapter 13: IP Multicast Operations

13.1 IP Multicast Addressing, Group Management (IGMPv1/v2/v3) & IGMP Snooping 13.2 Protocol Independent Multicast (PIM-SM, PIM-SSM & Bidir-PIM) 13.3 Rendezvous Point (RP) Distribution Mechanisms

14 Chapter 14: Network Assurance & Monitoring

14.1 Diagnostic Utilities, Conditional Debugging & Path MTU Discovery 14.2 Syslog Architecture, Logging Facilities & Severity Levels 14.3 SNMPv1/v2c/v3 Security & Flexible NetFlow (FNF) Architecture 14.4 Switched Port Analyzer (SPAN, RSPAN, ERSPAN) & IP SLA Object Tracking

15 Chapter 15: Catalyst Center Assurance & Controller Operations

15.1 Cisco Catalyst Center (DNA Center) Assurance & AI Network Analytics 15.2 Cisco Catalyst Center Device Onboarding & Software Image Management (SWIM)

16 Chapter 16: Enterprise Security & Access Control

16.1 Device Hardening, AAA Architecture & RADIUS/TACACS+ 16.2 Access Control Lists (ACLs) for Infrastructure Security 16.3 Control Plane Policing (CoPP) & Control Plane Protection (CPPr) 16.4 Layer 2 Infrastructure Security Features 16.5 IEEE 802.1X Port-Based Authentication & MAB

17 Chapter 17: Threat Defense & API Security

17.1 Enterprise VPN Technologies (DMVPN Phase 1/2/3 & FlexVPN) 17.2 Next-Generation Threat Defense & Secure Access Service Edge (SASE)

18 Chapter 18: Network Automation, Programmability & Data Modeling

18.1 Python Fundamentals for Network Engineers & Cisco Libraries 18.2 YANG Data Modeling Language (RFC 6020/7950) & Model Types 18.3 REST API Architecture, HTTP Verbs, Security & Cisco Controller APIs 18.4 Model-Driven Telemetry (MDT) & NETCONF/RESTCONF Operations

19 Chapter 19: Orchestration, EEM & AI Operations

19.1 Configuration Management & Infrastructure as Code (Ansible & Terraform) 19.2 Cisco Embedded Event Manager (EEM) & Intent-Based Networking

16.2 Access Control Lists (ACLs) for Infrastructure Security

Key Takeaways Explain This Topic AI

ENCOR v1.2 topic 5.2.a pairs ACLs with CoPP under 'infrastructure security features', so ACLs are examined as a device-hardening tool rather than as generic packet filtering.

Every IPv4 ACL ends with an invisible 'deny ip any any'; an ACL that contains only permit statements still blocks everything it does not explicitly allow, which is why an empty applied ACL denies all traffic.

A wildcard mask is the bitwise inverse of a subnet mask: 0 bits must match and 1 bits are ignored, so 10.1.4.0 0.0.3.255 matches the four contiguous /24s from 10.1.4.0 through 10.1.7.255.

IPv6 ACLs carry three implicit rules, not one: permit icmp any any nd-na and permit icmp any any nd-ns precede the implicit deny, so neighbour discovery survives a default-deny IPv6 ACL while it would break under an equivalent IPv4 design.

Filtering VTY access with 'access-class' under line vty is superior to an interface ACL because it protects the management plane regardless of which interface the session arrives on, and it costs no data-plane TCAM.

Last updated: August 2026

16.2 Access Control Lists (ACLs) for Infrastructure Security

ENCOR v1.2 topic 5.2 is "Configure and verify infrastructure security features", and it names exactly two: 5.2.a ACLs and 5.2.b CoPP . The pairing tells you how Cisco frames the topic. ACLs are not being examined as generic packet filtering — they are examined as the classification primitive that hardens the device itself, feeds CoPP (Section 16.3), steers PBR (Section 11.1), and gates management access. Everything below is oriented that way.

1. ACL Types and Number Ranges

• Type Numbered ranges Matches on Where to place
• Standard 1-99, 1300-1999 Source IPv4 address only Close to the destination

Extended 100-199, 2000-2699 Source and destination IP, protocol, L4 ports, flags, DSCP, TTL Close to the source

• Named Any name Same as standard or extended, chosen at creation Same rules
• IPv6 Named only — no numbers Source/destination IPv6, protocol, ports, extension headers Same rules

The expanded ranges (1300-1999 and 2000-2699) exist because the original ranges ran out. They behave identically to the base ranges and appear in exam distractors precisely because candidates forget them.

Named ACLs are the modern default. They are self-documenting, they support sequence-number editing without deleting and re-creating the list, and IPv6 supports nothing else.

Placement logic

The rule follows directly from what each type can match:

A standard ACL only knows the source. Placed near the source, it would block that source's traffic to every destination, not just the one you intended. So place it near the destination, where the surviving traffic is already narrowed.

An extended ACL knows source and destination. Placed near the source, it discards unwanted traffic on the first hop and saves bandwidth across the entire path.

2. Wildcard Mask Arithmetic

A wildcard mask is the bitwise inverse of a subnet mask . A 0 bit means "this bit must match"; a 1 bit means "ignore this bit".

• Subnet mask Wildcard mask Matches
• 255.255.255.255 0.0.0.0 (or the keyword host ) One address
• 255.255.255.0 0.0.0.255 One /24
• 255.255.252.0 0.0.3.255 Four contiguous /24s
• 255.255.240.0 0.0.15.255 Sixteen contiguous /24s
• 0.0.0.0 255.255.255.255 (or the keyword any ) Everything

Worked example: access-list 10 permit 10.1.4.0 0.0.3.255 . The third octet wildcard is 3, binary 00000011 , so the low two bits of the third octet are free. Starting at 4 ( 00000100 ), the free bits produce 4, 5, 6, and 7. The statement therefore matches 10.1.4.0 through 10.1.7.255 .

Wildcards do not have to be contiguous, which enables a useful trick: permit 10.1.1.0 0.0.0.254 matches only even-numbered hosts, because the last bit is forced to 0. Contiguous masks are the norm, but the exam has been known to show a discontiguous one to check that you are reading bits rather than pattern-matching CIDR.

3. Evaluation Order and the Implicit Deny

Three rules govern every ACL and they are absolute:

Top to bottom, first match wins. Once a packet matches an entry, evaluation stops. Nothing below is considered.

There is an implicit deny ip any any at the end of every ACL. It is never displayed by show access-lists and never increments a visible counter.

An ACL that is created but not applied filters nothing. Conversely, an ACL that is applied but empty denies everything, because only the implicit deny remains.

• Rule 1 is the source of the classic ordering bug: ! WRONG - the specific host permit is unreachable
• ip access-list extended WEB-FILTER
• 10 deny tcp 10.1.1.0 0.0.0.255 any eq 443
• 20 permit tcp host 10.1.1.50 any eq 443 <-- never evaluated

Host 10.1.1.50 is inside 10.1.1.0/24, so it matches entry 10 and is denied. Entry 20 is dead code. Specific entries must precede general ones.

Editing with sequence numbers

Named ACLs (and numbered ACLs in named-configuration mode) support in-place editing: ip access-list extended WEB-FILTER

• no 10 ! remove the offending entry
• 5 permit tcp host 10.1.1.50 any eq 443 ! insert BEFORE the deny

!

• Router# show access-lists WEB-FILTER
• Extended IP access list WEB-FILTER
• 5 permit tcp host 10.1.1.50 any eq 443
• 20 deny tcp 10.1.1.0 0.0.0.255 any eq 443 (14209 matches)

!

Router(config)# ip access-list resequence WEB-FILTER 10 10 ! renumber 10,20,30...

Without sequence numbers, editing a legacy numbered ACL with no access-list 100 deletes the entire list , instantly applying the implicit deny to a production interface. This is the single most common way engineers lock themselves out of a device.

4. Direction, and Why Inbound Is Cheaper

An ACL is applied per interface per direction with ip access-group <acl> {in | out} . Only one IPv4 ACL per interface per direction. INBOUND ACL OUTBOUND ACL

• packet arrives packet arrives
• | |
• [ inbound ACL ] <-- evaluated FIRST [ routing lookup ]
• | permit |
• [ routing lookup ] [ outbound ACL ]
• | | permit
• [ egress ] [ egress ]

• Denied packets never consume a routing Denied packets consume a routing
• lookup -> cheaper lookup before being discarded

A further asymmetry that the exam exploits: an outbound ACL does not filter traffic generated by the router itself. Packets sourced by the local control plane — routing protocol hellos, syslog, SNMP traps, ping from the CLI — bypass the outbound ACL on the egress interface. If you need to constrain router-originated traffic, use CoPP, a local policy, or protocol-specific controls such as ntp access-group .

5. Infrastructure ACLs (iACL)

An infrastructure ACL is applied at the network edge and denies traffic destined to the infrastructure address space, while permitting transit traffic through it. The insight is that no external host has any legitimate reason to send packets to a router's loopback or link addresses. ip access-list extended INFRASTRUCTURE-IN

• ! 1. Explicitly permit the few external peers that must reach us
• permit tcp host 203.0.113.9 host 198.51.100.1 eq bgp
• permit tcp host 203.0.113.9 eq bgp host 198.51.100.1
• ! 2. Deny everything else destined TO infrastructure space
• deny ip any 198.51.100.0 0.0.0.255
• ! 3. Permit all transit traffic THROUGH
• permit ip any any

!

• interface GigabitEthernet0/0/0
• description Internet edge
• ip access-group INFRASTRUCTURE-IN in

The ordering is the whole design: permit the known peers, deny the infrastructure block, then permit transit. Reversing steps 2 and 3 would make the deny unreachable and the iACL worthless.

iACL and CoPP are complementary, not redundant. The iACL keeps attack traffic out of the infrastructure address space at the edge; CoPP (Section 16.3) rate-limits whatever still reaches the route processor, including traffic sourced from inside the network. A hardened design uses both.

6. Protecting the Management Plane with access-class

Filtering SSH access with an interface ACL is fragile — you would need the ACL on every interface through which a session could arrive, and you would have to maintain it forever. access-class under line vty is the correct tool: ip access-list standard MGMT-HOSTS

permit 10.10.250.0 0.0.0.255

!

• line vty 0 15
• transport input ssh
• access-class MGMT-HOSTS in
• exec-timeout 5 0
• login authentication default

This filters at the VTY layer regardless of ingress interface, and because it never touches the data plane it consumes no ACL TCAM . On modern IOS-XE the vty-filter form of the command also supports specifying a VRF.

The trap: access-class ... in on a VTY line filters incoming sessions to the router . access-class ... out restricts where sessions may be initiated from the router — a different and much less commonly needed control.

7. IPv6 ACLs and the Neighbour Discovery Exemption

IPv6 ACLs are named only, and they carry three implicit entries rather than one: permit icmp any any nd-na <-- Neighbour Advertisement

• permit icmp any any nd-ns <-- Neighbour Solicitation
• deny ipv6 any any

This exists because IPv6 has no ARP; neighbour discovery is ICMPv6. Without the exemption, applying any IPv6 ACL would break Layer 2 address resolution on the segment and black-hole the interface.

The critical consequence: if you write an explicit deny ipv6 any any at the end of your own IPv6 ACL — a habit many engineers carry over from IPv4 to make the deny visible in counters — you override the implicit ND permits and break neighbour discovery . If you want a visible deny counter on IPv6, you must first restate the ND permits: ipv6 access-list IPV6-EDGE-IN

• permit tcp any 2001:db8:10::/64 eq 443
• permit icmp any any nd-na
• permit icmp any any nd-ns
• deny ipv6 any any log

This dual-stack asymmetry is exactly the kind of detail ENCOR v1.2 targets given the exam's explicit emphasis on IPv4 and IPv6 parity.

8. ACL Types by Attachment Point and Their Evaluation Order

On a Catalyst multilayer switch three distinct ACL families can act on the same frame:

• Family Attached to Scope
• PACL (Port ACL) A Layer 2 physical switchport That port only; ingress only
• VACL (VLAN map) A VLAN All traffic within and entering the VLAN, both directions
• RACL (Router ACL) An SVI or routed port Routed traffic only

For a frame that is bridged within a VLAN and then routed out, the evaluation order is PACL, then VACL, then RACL . A packet must survive every stage that applies to it. When a stem describes traffic being blocked "even though the SVI ACL permits it", the answer is almost always a PACL or VACL earlier in the chain.

• 9. Logging, Counters, and Verification Router# show access-lists MGMT-HOSTS
• Standard IP access list MGMT-HOSTS
• 10 permit 10.10.250.0, wildcard bits 0.0.0.255 (8241 matches)

• Router# clear access-list counters MGMT-HOSTS
• Router# show ip interface GigabitEthernet0/0/1 | include access list
• Outgoing access list is not set
• Inbound access list is INFRASTRUCTURE-IN

The log keyword sends a syslog message on match; log-input additionally records the ingress interface and source MAC, which is what you want when hunting a spoofed source.

The performance warning is exam-relevant. A logged ACE forces matching packets to be punted from the hardware CEF path to the route processor , because ASICs cannot generate syslog. On a high-rate flow this converts a line-rate hardware drop into a CPU event and can itself become the outage. Use log on low-volume deny entries during a specific investigation, rate-limit it with ip access-list logging interval , and remove it afterwards. This is also why an iACL is the right place for volume drops and a logged ACE is not.

Verification habit: a permit entry showing zero matches means either the traffic is not arriving or an earlier entry is catching it. Read the counters before rewriting the logic.