16.2 Access Control Lists (ACLs) for Infrastructure Security

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

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".

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:

1. Top to bottom, first match wins. Once a packet matches an entry, evaluation stops. Nothing below is considered.
2. 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.
3. 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:

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.