Cisco IOS XR ACL Configuration and Verification

IOS XR access lists look superficially like IOS but the differences bite: the ipv4 access-list naming model, mandatory sequence numbers, atomic updates, and the way an ACL application can silently fail to attach. This article covers building extended and IPv6 ACLs, applying them to interfaces and lines, reading the counters that prove they work, and the specific traps that produce "the ACL is there but traffic is still passing" or, worse, "everything is dropped".

ACL types and naming on IOS XR

ipv4 access-list NAME       named ACL (preferred)
ipv4 access-list 100        numbered, still allowed
ipv6 access-list NAME6
prefix-set / as-path-set    routing policy only, NOT traffic filtering
object-group network/host  reusable address and port groups

Anything that filters routing advertisements belongs in RPL, not an interface ACL — see IOS XR RPL and prefix-sets.

Building an extended ACL

ipv4 access-list EDGE-IN
 10 permit tcp any host 203.0.113.10 eq 443
 20 permit tcp any host 203.0.113.10 eq 80
 30 permit icmp any any echo-reply
 40 permit icmp any any unreachable
 50 deny   ipv4 any any log
!
commit

Sequence numbers are mandatory on IOS XR (10, 20, 30...). Inserting later
is a matter of picking a gap, e.g. 15 — you cannot rely on "append at end".

Reusable objects

object-group network INTERNAL-SERVERS
 10.10.1.20 255.255.255.255
 10.10.1.21 255.255.255.255
!
object-group port WEB-PORTS
 eq 80
 eq 443
!
ipv4 access-list MGMT-IN
 10 permit tcp object-group NMS-HOSTS object-group INTERNAL-SERVERS object-group WEB-PORTS
 20 deny ipv4 any any

Object groups keep the ACL small enough to audit, and they are the practical answer to ACLs that grow past a few hundred lines.

Applying the ACL

! to an interface (ingress recommended)
interface HundredGigE0/0/0/0
 ipv4 access-group EDGE-IN ingress
!
! to a line (management access)
line default
 access-class MGMT-IN ingress
!
! to the control plane (LPTS / CoPP-style)
control-plane
 ! see LPTS for policer mapping

Applying to line default without a permit for your own management subnet is the classic way to lock yourself out; in XR this is at least recoverable with the specific commit/idle timeout behaviour, but a commit confirmed idiom is safer:

commit confirmed 5
! ... apply ACL ...
show run line default
commit      # confirm before the timer expires

Verification

show access-lists EDGE-IN              ! entries + per-ACE match counters
show access-lists EDGE-IN hardware ingress location 0/0/CPU0
                                        ! confirm it is programmed in hardware
show ipv4 interface HundredGigE0/0/0/0 ! is the ACL actually attached?
show access-lists usage                 ! ACL memory/TCAM consumption
show running-config ipv4 access-list EDGE-IN

The two failure modes map cleanly onto these commands. If show access-lists shows zero matches on the deny line while traffic is apparently blocked, the ACL is not attached or not programmed in hardware. If counters increment on a deny you did not expect, the entry ordering is wrong.

Troubleshooting table

Symptom                              Cause
Traffic still flows despite deny      ACL not applied, or applied in wrong
                                     direction, or not in the direction of flow
Everything dropped                     missing permit for return traffic or for
                                     management/control protocols
ACL present but counter frozen         not programmed in hardware; check usage
Intermittent pass                     fragment handling / reordering rules
Management lost                        access-class applied without permit
TCAM full                             show access-lists usage; consolidate with
                                     object groups, use compression

Control-plane traffic is filtered by LPTS policers rather than interface ACLs in many cases, and a confused ACL interacting with LPTS is a common source of "punched" but still-dropped management traffic. ACL-based forwarding and policy-based routing on the same platform are worth reviewing together: PBR verification. If you are fighting packet loss that looks ACL-related, rule out NP counters first via IOS XR input drops troubleshooting.

FAQ

Q: Are implicit denies present? Yes — every ACL ends with an implicit deny, so an explicit deny with log is only for visibility.
Q: Do I need to worry about reordering? Reordering ACEs can be non-atomic. On platforms that support it, use atomic update options or accept a brief window; otherwise schedule the change.
Q: How do I count traffic per entry? show access-lists gives per-ACE counters; for historic trends export them via SNMP or telemetry, as described in IOS XR model-driven telemetry.
Q: IPv6 ACLs too? Yes, with ipv6 access-list and ipv6 access-group, but address syntax has no wildcard masks — use prefix lengths.

原文链接：https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/24xx/ip-addresses/configuration/guide/b-ip-addresses-cg-asr9000-24xx/Implementing-access-lists-and-prefix-lists.html