IP Addresses and Services Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

PDF

IP Addresses and Services Configuration Guide for Cisco 8000 Series Routers, IOS XR Releases

Access Control Lists

Updated: August 12, 2026

Want to summarize with AI?

Log in

This topic describes access control lists (ACLs) on the Cisco 8000 Series Router, which perform packet filtering to control which packets move through the network and where.

The Access Control List (ACL) is a security mechanism that

  • controls packet movement through the network

  • restricts user and device access, and

  • defines network traffic profiles through collections of entries.

An ACL consists of one or more access control entries (ACE) that collectively define the network traffic profile. Access control entries (ACE) are entries in an ACL that describe the access rights related to a particular security identifier or user. This profile can then be referenced by Cisco IOS XR software features such as traffic filtering, route filtering, QoS classification, and access control. There are two types of ACLs:

  • Standard ACLs—Verify only the source IP address of the packets. Traffic is controlled by the comparison of the address or prefix configured in the ACL, with the source address found in the packet.

  • Extended ACLs—Verify more than just the source address of the packets. Attributes such as destination address, specific IP protocols, User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) port numbers, Differentiated Services Code Point (DSCP), and so on are validated. Traffic is controlled by a comparison of the attributes stated in the ACL with those in the incoming or outgoing packets.

Cisco IOS XR does not differentiate between standard and extended access lists. Standard access list support is provided for backward compatibility.

How an IP ACL works

An ACL (Access Control List) is a sequential list consisting of permit and deny statements that apply to IP addresses and possibly upper-layer IP protocols. The ACL has a name by which it is referenced. Many software commands accept an access list as part of their syntax.

An ACL can be configured and named, but it is not in effect until the ACL is referenced by a command that accepts an access list. Multiple commands can reference the same access list. An ACL can control traffic arriving at the router or leaving the router, but not traffic originating at the router.

Summary

Source address and destination addresses are two of the most typical fields in an IP packet on which to base an access list. The key fields on which an ACL filters packets are:

  • Source address: Specify source addresses to control packets from certain networking devices or hosts.

  • Destination address: Specify destination addresses to control packets being sent to certain networking devices or hosts.

  • Transport layer information: You can also filter packets on the basis of transport layer information, such as whether the packet is a TCP, UDP, Internet Control Message Protocol (ICMP), or Internet Group Management Protocol (IGMP) packet.

This image illustrates the workflow of an ACL.

Workflow

ACL process and rules

Use the these process and rules when configuring an IP ACL:

  • The software tests the source or destination address or the protocol of each packet being filtered against the conditions in the access list, one condition (permit or deny statement) at a time.

  • If a packet does not match an access list statement, the packet is then tested against the next statement in the list.

  • If a packet and an access list statement match, the remaining statements in the list are skipped and the packet is permitted or denied as specified in the matched statement. The first entry that the packet matches determines whether the software permits or denies the packet. That is, after the first match, no subsequent entries are considered.

  • If the access list denies the address or protocol, the software discards the packet and returns an ICMP Host Unreachable message. ICMP is configurable in the Cisco IOS XR software.

    ICMP type and code such as ECHO, ECHO-REPLY, MASK-REPLY, MASK-REQUEST, and so on are supported.

  • If no conditions match, the software drops the packet because each access list ends with an unwritten or implicit deny statement. That is, if the packet has not been permitted or denied by the time it was tested against each statement, it is denied.

  • The access list should contain at least one permit statement or else all packets are denied.

  • Because the software stops testing conditions after the first match, the order of the conditions is critical. The same permit or deny statements specified in a different order could result in a packet being passed under one circumstance and denied in another circumstance.

  • Only one access list per interface, per protocol, per direction is allowed.

  • Inbound access lists process packets arriving at the router. Incoming packets are processed before being routed to an outbound interface. An inbound access list is efficient because it saves the overhead of routing lookups if the packet is to be discarded because it is denied by the filtering tests. If the packet is permitted by the tests, it is then processed for routing. For inbound lists, permit means continue to process the packet after receiving it on an inbound interface; deny means discard the packet.

  • Outbound access lists process packets before they leave the router. Incoming packets are routed to the outbound interface and then processed through the outbound access list. For outbound lists, permit means send it to the output buffer; deny means discard the packet.

  • An access list can not be removed if that access list is being applied by an access group in use. To remove an access list, remove the access group that is referencing the access list and then remove the access list.

  • Before removing an interface, which is configured with an ACL that denies certain traffic, you must remove the ACL and commit your configuration. If this is not done, then some packets are leaked through the interface as soon as the no interface <interface-name> command is configured and committed.

  • An access list must exist before you can use the ipv4 | ipv6 access-group command.

Helpful hints for creating IP access lists

Consider these tips when creating an ACL:

  • Create the ACL before applying it to an interface.

  • Organize your ACL so that more specific references in a network or subnet appear before more general ones.

  • To make the purpose of individual statements more easily understood at a glance, you can write a helpful remark before or after any statement.

Wildcard mask ACL address filtering

The wildcard mask is a filtering mechanism that

  • indicates whether the software checks or ignores corresponding IP address bits when comparing the address bits in an access-list entry to a packet being submitted to the access list

  • selects single or multiple IP addresses for permit or deny tests, and

  • enables noncontiguous bit manipulation for granular control.

The system processes wildcard masks according to these rules:

  • A wildcard mask bit 0 means check the corresponding bit value.

  • A wildcard mask bit 1 means ignore that corresponding bit value.

  • Wildcard masking for IP address bits uses the number 1 and the number 0 to specify how the software treats the corresponding IP address bits. A wildcard mask is sometimes referred to as an inverted mask, because a 1 and 0 mean the opposite of what they mean in a subnet (network) mask.

  • You do not have to supply a wildcard mask with a source or destination address in an access list statement. If you use the host keyword, the software assumes a wildcard mask of 0.0.0.0.

    Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard masks allow noncontiguous bits in the mask.

  • You can utilize Classless Inter-Domain Routing (CIDR) format as an alternative to explicit wildcard bits. For example, the IPv4 address 1.2.3.4 0.255.255.255 corresponds to 1.2.3.4/8 and for IPv6 address 2001:db8:abcd:0012:0000:0000:0000:0000 corresponds to 2001:db8:abcd:0012::0/64.

Configuration guidelines for ACLs

These are the guidelines for configuring ACLs:

  • If the Ternary content-addressable memory (TCAM) utilization is high and large ACLs are modified, then an error may occur. During such instances, remove the ACL from the interface and reconfigure the ACL. Later, reapply the ACL to the interface.

  • ACL commit failures caused by TCAM Out of Resources (OOR) can lead to inconsistent behavior, including partial TCAM programming on other slices and misleading error messages for subsequent items in batch commits. To prevent this, apply ACL configurations one interface at a time with separate commits. After an OOR failure, verify TCAM usage and consider a line card reload to ensure resource consistency.

  • Modifying an ACL when it is attached to the interface is supported.

  • You can configure an ACL name with a maximum of 64 characters.

  • You can configure an ACL name to comprise of only letters and numbers.

  • The ACL ID scale per protocol for IPv4 and IPv6 traffic in each direction:

    • The ACL scale for the Cisco 8200 series router is 15 ACL IDs per slice pair, 45 ACL IDs per NPU, 45 ACL IDs per line card, and 45 ACL IDs per router.

    • The ACL scale for the Cisco 8812 series routers with 8800-LC-48H line cards is 15 ACL IDs per slice pair, 30 ACL IDs per NPU, 60 ACL IDs per line card, and 720 ACL IDs per router.

    • The ACL scale for the Cisco 8812 series routers with 8800-LC-36FH-M line cards is 15 ACL IDs per slice pair, 30 ACL IDs per NPU, 120 ACL IDs per line card, and 1440 ACL IDs per router.

  • An ACL-dependent feature refers to a capability in network systems that relies on Access Control Lists (ACLs) for its operation. These features include both global such as Lawful Intercept (LI), BGP Flow Specification (BGPFS) and interface-level configurations, such as Quality of Service with ACL (QoS-ACL), Security ACL, SPAN ACL, Qos Policy Propagation via BGP (QPPB), Policy Based Routing (PBR), Peering QoS, and L2 ACL for packets with L3 payload.

    An interface, whether physical or virtual, supports the configuration of up to four ACL dependent features, such as ACLs, QoS with ACL, BGP Flow Specification, SPAN ACL, and Lawful Intercept. To add a new feature, such as Policy-Based Routing, you must first remove one of the existing features and then configure the new feature.

Restrictions for configuring ACLs

These restrictions apply for ACLs:

  • IPv4 and IPv6 ACLs are not supported for loopback and interflex interfaces.

  • Filtering of Multiprotocol Label Switching (MPLS) packets through interface ACL is not supported.

Comments in ACLs

You can include comments (remarks) about entries in any named IP ACL using the remark access list configuration command. The remarks make the ACL easier for the network administrator to understand and scan. Each remark line is limited to 255 characters.

The remark can go before or after a permit or deny statement. You should be consistent about where you put the remark so it is clear which remark describes which permit or deny statement. For example, it would be confusing to have some remarks before the associated permit or deny statements and some remarks after the associated statements. Remarks can be sequenced.

Remember to apply the access list to an interface or terminal line after the access list is created.