Configuring AACL Rules

To configure an AACL rule, include the rule rule-name statement at the [edit services aacl] hierarchy level:

rule rule-name {match-direction (input | output | input-output);term term-name {from {application-group-any;application-groups [ application-group-names ];applications [ application-names ];destination-address address <any-unicast>;destination-address-range low minimum-value high maximum-value;destination-prefix-list list-name;source-address address <any-unicast>;source-address-range low minimum-value high maximum-value;source-prefix-list list-name;}then {(accept | discard);count (application | application-group | application-group-any | none);forwarding-class class-name;policer policer-name;}}}

Each AACL rule consists of a set of terms, similar to a filter configured at the [edit firewall] hierarchy level. A term consists of the following:

from statement—Specifies the match conditions and applications that are included and excluded.
then statement—Specifies the actions and action modifiers to be performed by the router software.

The following sections explain how to configure the components of AACL rules:

Configuring Match Direction for AACL Rules

Each rule must include a match-direction statement that specifies the direction in which the rule match is applied. To configure where the match is applied, include the match-direction statement at the [edit services aacl rule rule-name] hierarchy level:

match-direction (input | output | input-output);

If you configure match-direction input-output, bidirectional rule creation is allowed.

The match direction is used with respect to the traffic flow through the services PIC or DPC. When a packet is sent to the PIC or DPC, direction information is carried along with it.

With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.

With a next-hop service set, packet direction is determined by the interface used to route the packet to the services PIC or DPC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the PIC or DPC, the packet direction is output. For more information on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.

On the PIC or DPC, a flow lookup is performed. If no flow is found, rule processing is performed. All rules in the service set are considered. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that matches the packet direction are considered.

Configuring Match Conditions in AACL Rules

To configure AACL match conditions, include the from statement at the [edit services aacl rule rule-name term term-name] hierarchy level:

from {application-group-any;application-groups [ application-group-names ];applications [ application-names ];destination-address address <any-unicast>;destination-address-range low minimum-value high maximum-value;destination-prefix-list list-name;source-address address <any-unicast>;source-address-range low minimum-value high maximum-value;source-prefix-list list-name;}

Only IPv4 source and destination addresses are supported. You can use either the source address or the destination address as a match condition, in the same way that you configure a firewall filter; for more information, see the Junos Policy Framework Configuration Guide.

Alternatively, you can specify a list of source or destination prefixes by configuring the prefix-list statement at the [edit policy-options] hierarchy level and then including either the destination-prefix-list or the source-prefix-list statement in the AACL rule. For an example, see Example: Configuring AACL Rules.

If you omit the from term, the AACL rule accepts all traffic and the default protocol handlers take effect:

User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Control Message Protocol (ICMP) create a bidirectional flow with a predicted reverse flow.
IP creates a unidirectional flow.

You can also include application and application group definitions you have configured at the [edit services application-identification] hierarchy level; for more information, see the topics in Application Identification.

To apply one or more specific application protocol definitions, include the applications statement at the [edit services aacl rule rule-name term term-name from] hierarchy level.

To apply one or more sets of application group definitions you have defined, include the application-groups statement at the [edit services aacl rule rule-name term term-name from] hierarchy level.

Note: If you include one of the statements that specifies application protocols, the router derives port and protocol information from the corresponding configuration at the [edit services application-identification] hierarchy level; you cannot specify these properties as match conditions.

To consider any application group defined in the database as a match, include the application-group-any statement at the [edit services aacl rule rule-name term term-name from] hierarchy level.

Configuring Actions in AACL Rules

To configure AACL actions, include the then statement at the [edit services aacl rule rule-name term term-name] hierarchy level:

then {(accept | discard);(count (application | application-group | application-group-any | none) | forwarding-class class-name);}

You must include one of the following actions:

accept—The packet is accepted and sent on to its destination.
discard—The packet is not accepted and is not processed further.

When you select accept as the action, you can optionally configure one or both of the following action modifiers. No action modifiers are allowed with the discard action.

count (application | application-group | application-group-any | none)—For all accepted packets that match the rules, record a packet count using AACL statistics practices. You can specify one of the following options; there is no default setting:

application—Count the application that matched in the from clause.
application-group—Count the application group that matched in the from clause.
application-group-any—Count all application groups that match from application-group-any under the any group name.
none—Same as not specifying count as an action.

Note: During the time that the application identification (APPID) feature has not yet made a final determination of the application associated with a given flow, the flow does not contribute to any per-subscriber or per-application statistics collection. For more information, see Best-Effort Application Identification of DPI-Serviced Flows.

forwarding-class class-name—Specify the packets’ forwarding-class name.

You can optionally include a policer that has been specified at the [edit firewall] hierarchy level. Only the bit-rate and burst-size properties specified for the policer are applied in the AACL rule set. The only action application when a policer is configured is discard. For more information on policer definitions, see the Junos Policy Framework Configuration Guide.