Layer 3 ACL configuration guidelines

We present configuration guidelines for all ACLs, then for Layer 3 ACLs, then for L3 ACLs applied to a user interface, then for ACLs applied to the management interface, and then guidelines for receive-path ACLs (rACLs).

The following guidelines are for all ACLs:

An ACL name can be up to 63 characters long, and must begin with a–z, A–Z or 0–9. You can also use underscore (_) or hyphen (-) in an ACL name, but not as the first character.
On any given device, an ACL name must be unique among all ACL types (MAC/IPv4/IPv6, standard or extended).
The order of the rules in an ACL is critical. The first rule that matches the traffic stops further processing of the rules. For example, following a permit match, subsequent deny or hard-drop rules do not override the permit.
When you create an ACL rule, you have the option of specifying the rule sequence number. If you create a rule without a sequence number, it is automatically assigned a sequence number incremented above the previous last rule.
To modify an ACL rule, delete it and then replace it with a rule of the same seq number.
You can apply a maximum of five ACLs to a user interface, as follows:
- One ingress MAC ACL—if the interface is in switchport mode
- One egress MAC ACL—if the interface is in switchport mode
- One ingress IPv4 ACL
- One egress IPv4 ACL
- One ingress IPv6 ACL

Guidelines for all Layer 3 ACLs

(All supported devices) In addition to the guidelines that apply to all ACLs, the following guidelines are relevant for Layer 3 ACLs:

In ingress Layer 3 ACLs, hard-drop rules affect control protocol and MY IP packets.
On Management interfaces, a hard-drop works the same as a denyaction.
Although L3 ACL deny rules do not drop protocol packets, best practice is to define an explicit permit rule for needed protocols.

( SLX 9150, and SLX 9250 devices) The following additional guidelines are relevant for Layer 3 ACLs:

For tunnel-termination cases, ingress ACLs are applicable for inner headers.
For tunnel-origination cases, egress ACLs are applicable for outer headers.

( SLX 9540 and SLX 9640 devices) The following additional guidelines are relevant for Layer 3 ACLs:

In egress Layer 3 ACLs, deny and hard-drop rules do not affect control protocol and MY IP packets.

Guidelines for Layer 3 ACLs applied to user interfaces

(All supported devices) In addition to the previous guidelines, the following guidelines are relevant for Layer 3 ACLs applied to user interfaces:

There is an implicit "deny" rule at the end of every Layer 3 ACL applied to a user interface. This denies all L3 streams that do not match any of the configured rules in the ACL.
Traffic generated by the CPU—for example, echo request packets—are not filtered by egress IPv4 ACLs.

( SLX 9540 and SLX 9640 devices) In addition to the previous guidelines, the following guidelines are relevant for Layer 3 ACLs applied to user interfaces:

Egress IPv4 ACLs are applicable only for routed traffic.

Guidelines for ACLs applied to the management interface

The following protection guards against malicious ICMP timestamp requests (icmp-type 13):

ICMP timestamp requests and responses are dropped by default.
If an ACL with a permit icmp any any rule is applied to the management interface, such a rule permits ICMP timestamp requests. However, ICMP timestamp responses are blocked.

The following additional guidelines are relevant for Layer 3 ACLs applied to the management interface:

When an ACL is bound to the management interface, ICMP packet types are implicitly permitted. An implicit deny entry is programmed for the rest of the non-matching traffic.
(Standard ACLs) Only packets with TCP/UDP protocols are filtered for the configured match condition (for example, SIP).
(Standard ACLs) By default, TCP, UDP, ESP, AH, and ICMP are allowed.
(Extended ACLs) Applying a permit or deny UDP ACL to the management interface enacts an implicit deny for TCP; however, a ping will succeed.
(Extended ACLs) Applying a permit or deny ACL for a specific UDP port enacts an implicit deny for all other UDP ports.
(Extended ACLs) Applying a permit or deny ACL for a specific TCP port enacts an implicit deny for all other TCP ports.
You can apply a maximum of two ACLs to the management interface, as follows:
- One ingress IPv4 ACL
- One ingress IPv6 ACL
Before downgrading firmware, unbind any ACLs on the management interface.

If no ACLs are applied to the device management interface, ICMP pings are allowed. In addition, the following default rules are effective:

seq 0 permit tcp any any eq 22
seq 1 permit tcp any any eq 23
seq 2 permit tcp any any eq 80
seq 3 permit tcp any any eq 443
seq 4 permit udp any any eq 161
seq 5 permit udp any any eq 123
seq 6 permit tcp any any range 600-65535
seq 7 permit udp any any range 600-65535

Guidelines for rACLs

(All supported devices) The following additional guidelines are relevant for all receive-path ACLs (rACLs):

Interface ACLs and rACLs share the same resource (database-table).
In all rACLs, explicit and implicit rules are processed in the following order:
1. Explicit rules, in an order determined by their seq numbers.
2. An implicit deny any my-ip rule that affects all other CPU-bound traffic.
Under inband management, you need to include permit rules for your telnet/SSH access to the device.

( SLX 9150, and SLX 9250 devices) The following additional guidelines are relevant for all receive-path ACLs (rACLs):

IPv4 rACLs apply to multicast datapath traffic only if multicast destination-IPs are explicitly specified in rules.
In an IPv4 rACL rule, if a destination IP is not specified, my-ip (IP addresses configured on any Layer 3 interface) is interpreted as the destination IP. Such rules do not filter multicast traffic.
Multicast traffic is first filtered by rACLs, then by interface ACLs.

( SLX 9540 and SLX 9640 devices) The following additional guidelines are relevant for all receive-path ACLs (rACLs):

rACLS are supported only for unicast, routed traffic.
In an IPv4 rACL rule, if a destination IP is not specified, matches apply to all IP addresses configured on the device.

(All supported devices) The following guidelines are relevant for multiple rACLs:

Multiple rACLs are supported only in the default TCAM profile.
You can apply a maximum of 400 receive-path ACLs to a device, as follows:
- 200 IPv4 receive-path ACLs
- 200 IPv6 receive-path ACLs
Supported sequence numbers for rACLs range from 1 through 2047.
If you apply an rACL to a device without specifying a sequence number, numbers are assigned automatically, as follows:
- The first rACL applied to the device is assigned 10.
- Each additional rACL applied is assigned an increment of 10 above the highest applied sequence number.

The following table compares the effect of deny or hard-drop rACL matches for different types of packets.

Table 1. Effect of deny and hard-drop matches on different packet types
Packet type	Deny or hard-drop match
Control packets	Not dropped
Data packets	NA
My IP packets (incl. ICMP, control or data)	Dropped