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.
ethernet-services access-list EXAMPLE
permit host 1111.2222.3333 host 1111.2222.4444ICMP 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
copy access-list ipv4 NAME NEW-NAME“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:
RP/0/RP0/CPU0:XR1(config)#ipv4 access-list STANDARD
RP/0/RP0/CPU0:XR1(config-ipv4-acl)#permit host 1.2.3.4
RP/0/RP0/CPU0:XR1(config-ipv4-acl)#root
RP/0/RP0/CPU0:XR1(config)#show
ipv4 access-list STANDARD
10 permit ipv4 host 1.2.3.4 anyImplicit 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.
RP/0/RP0/CPU0:XR1(config)#do sho run ipv4 access-list
Sat Feb 3 20:35:04.049 UTC
ipv4 access-list EX1
10 permit ipv4 1.2.3.0/24 any
!
ipv4 access-list EX2
10 permit ipv4 1.2.3.0 0.0.0.255 any
!
RP/0/RP0/CPU0:XR1(config)#
RP/0/RP0/CPU0:XR1(config)#do sho access-lists
Sat Feb 3 20:35:07.384 UTC
ipv4 access-list EX1
10 permit ipv4 1.2.3.0 0.0.0.255 any
ipv4 access-list EX2
10 permit ipv4 1.2.3.0 0.0.0.255 anyRemarks
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.
ipv4 access-list EX1
10 remark ACE1
11 permit ipv4 host 1.1.1.1 any
20 remark ACE2
21 permit ipv4 host 1.1.1.2 anyMatching 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.
permit tcp any any match-any + syn - finSeeing matches on an ACL
You cannot see matches to the ACL with a simple “show access-list” command:
RP/0/RP0/CPU0:XR1#show access-lists FILTER
Sat Feb 3 21:00:52.614 UTC
ipv4 access-list FILTER
10 deny ipv4 host 10.0.0.2 host 10.0.0.3
20 permit ipv4 any anyInstead you have to show the hardware information for that ACL. Note that this does work on XRv9K.
RP/0/RP0/CPU0:XR1#show access-lists FILTER hardware ingress location 0/0/CPU0
Sat Feb 3 21:00:27.130 UTC
ipv4 access-list FILTER
10 deny ipv4 host 10.0.0.2 host 10.0.0.3 (5 hw matches)
20 permit ipv4 any anyACL-based forwarding
ACL-based forwarding is essentially PBR for IOS-XR. You configure the nexthop directly on the ACE.
ipv4 access-list ABF_EXAMPLE
10 permit ipv4 host 10.0.0.2 host 10.0.0.3 nexthop1 ipv4 10.1.2.2
20 permit ipv4 any any
!
interface GigabitEthernet0/0/0/0.3012
ipv4 access-group ABF_EXAMPLE ingressChained 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.
ipv4 access-list CUSTOMER
10 permit ipv4 1.2.3.0/24 any
!
ipv4 access-list SP_INFRASTRUCTURE
10 deny ipv4 any 1.0.0.0/24
20 permit ipv4 any any
!
interface GigabitEthernet0/0/0/0.3012
ipv4 access-group common SP_INFRASTRUCTURE CUSTOMER ingressAbove, 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