# Notes - Security ACLs

### L2 ACL <a href="#id-1cf8dde3-d4d1-8040-a15d-e095ae08ef49" id="id-1cf8dde3-d4d1-8040-a15d-e095ae08ef49"></a>

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.4444
```



### ICMP host unreachable <a href="#id-1cf8dde3-d4d1-8092-a5c0-dcbce0f26c3a" id="id-1cf8dde3-d4d1-8092-a5c0-dcbce0f26c3a"></a>

By default, if a deny entry is matched, an ICMP host unreachable message is returned.



### Fields matched <a href="#id-1cf8dde3-d4d1-8094-bcff-fb3546e18dc7" id="id-1cf8dde3-d4d1-8094-bcff-fb3546e18dc7"></a>

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 <a href="#id-32c4e268-9312-4eb6-a19d-06266bcf9f66" id="id-32c4e268-9312-4eb6-a19d-06266bcf9f66"></a>

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 <a href="#id-7150ec95-8236-4216-b8a3-0865cae46293" id="id-7150ec95-8236-4216-b8a3-0865cae46293"></a>

An ACL can be copied from exec mode

```
copy access-list ipv4 NAME NEW-NAME
```



### “From us" traffic <a href="#id-69deea77-3c81-4894-b39b-6d8a9338fb9c" id="id-69deea77-3c81-4894-b39b-6d8a9338fb9c"></a>

An ACL applied in the egress on an interface will not match traffic generated locally by the router.



### Standard ACLs <a href="#c285c1fe-84f1-42a0-9de8-634878dee0b4" id="c285c1fe-84f1-42a0-9de8-634878dee0b4"></a>

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 any
```



### Implicit Deny <a href="#b7ed337f-07d5-4953-997f-f8595c51504c" id="b7ed337f-07d5-4953-997f-f8595c51504c"></a>

Just like IOS, IOS-XR uses an implicit deny statement at the end of every ACL.



### Wildcard Masks <a href="#d3370673-40ea-49ec-a5d8-f1cc4a526f40" id="d3370673-40ea-49ec-a5d8-f1cc4a526f40"></a>

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 any
```



### Remarks <a href="#e5cdd875-32fb-495b-969e-3dd42dffce1d" id="e5cdd875-32fb-495b-969e-3dd42dffce1d"></a>

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 any
```



### Matching Multiple TCP Flags <a href="#id-645a1d44-1c7c-4164-aada-b762fae0deb9" id="id-645a1d44-1c7c-4164-aada-b762fae0deb9"></a>

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 - fin
```



### Seeing matches on an ACL <a href="#id-96e21eb3-bec2-408a-ad87-42724e4c0fe7" id="id-96e21eb3-bec2-408a-ad87-42724e4c0fe7"></a>

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 any
```



Instead 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 any
```



### ACL-based forwarding <a href="#id-88795227-7080-461b-846f-38cfe09af25c" id="id-88795227-7080-461b-846f-38cfe09af25c"></a>

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 ingress
```



### Chained ACLs <a href="#cb5578df-4172-4221-b0da-2e8527791afb" id="cb5578df-4172-4221-b0da-2e8527791afb"></a>

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 ingress
```



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.
