Configuring 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:

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:

IPv4 and IPv6 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 Routing Policies, Firewall Filters, and Traffic Policers User 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 APPID Overview.

• 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.

• To consider any nested application defined in the database a match, include the nested-applications statement at the [edit services aacl rule rule-name term term-name from] hierarchy level. Nested applications are protocols that run on a parent application. For example, if the Facebook application runs on the parent application junos:http, the nested application is junos:http:facebook.

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:

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 | nested-application | 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.

  • nested-application—Count all nested applications that matched in the from clause.

  • none—Same as not specifying count as an action.

  Note:

  • When a session closes before APPID has identified nested applications, the session is treated as a best-effort session and AACL does not get the nested application information. In such cases, nested applications are reported as unknown applications.

  • 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 Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Logging AACL Flows Based on Application

You can now log AACL flows based on application. You can select a specific application or request information on unknown applications.

You can now configure AACL rules to match unknown applications. All existing actions that can apply to recognized applications can also apply to unknown applications. You can use the following statements at the [edit services aacl rule rule-name term term-name from] hierarchy level:

• application-group-any

• application-groups

• application-unknown

• applications

• nested-application-unknown

• nested-applications

The addition of matching application-unknown enables the specific logging of the input flows associated with applications that cannot be identified. Because logging is triggered by an input event, you must specify match-direction as input-output or input.

To configure logging of flows for AACL, include the match-direction input or match-direction input-output statement at the [edit services aacl rule rule-name] hierarchy level, include an applications or application-unknown statement at the [edit services aacl rule rule-name term term-name from] hierarchy level, and include only one log statement at the [edit services aacl rule rule-name term term-name then] hierarchy level. The log statements can include any of the following options:

• session-start

• session-end

• session-start-end-no-stats

• session-start-interim-end

• session-interim-end

• session-end