Notes - Security ACLs
L2 ACL
ACLs are available for L2 in addition to IPv4 and IPv6. An L2 ACL looks like this. It does not appear to be supported on XRv9000 nor XRd.
ICMP host unreachable
By default, if a deny entry is matched, an ICMP host unreachable message is returned.
Fields matched
Many protocols can be matched, and many fields of these protocols can be matched. For example, the DSCP value, TTL value, etc. can be matched.
Fragments
The fragments keyword means to only match non-initial fragments.
An ACE with L4 parameters, without the fragments keyword, will match non-fragmented packets and initial fragments.
Ac ACE with only L3 parameters, without the fragments keyword, will match all packets (non-frag, initial frag, non-initial frag).
The summary is:
ACE has fragments keyword?
ACE has only L3 information
ACE has L3+L4 information
No
Applies to all packets
Applies only to non-fragments and initial fragments. Applies to non-initial fragments for only the L3 portion of the ACE.
Yes
Only applies to non-initial fragments
Not configurable
The fragments keyword cannot be configured for an ACE that contains L4 information.
Copying ACLs
An ACL can be copied from exec mode
“From us" traffic
An ACL applied in the egress on an interface will not match traffic generated locally by the router.
Standard ACLs
IOS-XR does not differentiate between standard and extended ACLs. Instead, it allows you to use standard ACL syntax (only matching the source portion) and converts it to an extended ACL:
Implicit Deny
Just like IOS, IOS-XR uses an implicit deny statement at the end of every ACL.
Wildcard Masks
IOS-XR will internally convert CIDR format to a wildcard mask. Sometimes wildcard masks might be necessary to match special cases such as an odd octect, etc. You can either use CIDR notation or wilcard notation.
Remarks
Remarks take up their own sequence number, so you should be consistent about whether you place remarks before or after the statement they are referencing.
Matching Multiple TCP Flags
To match multiple TCP flags in one ACE, you can use match-any (”or”) or match-all (”and”).
A + means the flag is set, and a - means the flag is not set.
Seeing matches on an ACL
You cannot see matches to the ACL with a simple “show access-list” command:
Instead you have to show the hardware information for that ACL. Note that this does work on XRv9K.
ACL-based forwarding
ACL-based forwarding is essentially PBR for IOS-XR. You configure the nexthop directly on the ACE.
Chained ACLs
This feature allows multiple ACLs to be applied to an interface. The use-case for this is that you have one “common” ACL which is applied to all interfaces to protect the SP’s infrastructure, and another customer-specific ACL for that particular interface.
Above, the SP Infrastructure ACL would be applied to all interfaces, and protects traffic from hitting their routers. The customer ACL only permits traffic sourced from 1.2.3.0/24.
There is a huge benefit to this, which is that when the common ACL needs to be updated, you simply update that one ACL. If these were collapsed into a single ACL, you would have to modify the shared rule among all individual ACLs which would be very difficult.
The common/chained ACL is applied first, before the interface ACL.
This feature is only supported in the ingress direction. Also this feature doesn’t support object groups.
You can also apply only the common ACL alone, without a second ACL.
This feature produces less entries in the TCAM, which makes it more scalable than combining these rules into one ACL on each interface.
Last updated