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; nested-applications [ nested-application-names ]; nested-application-unknown 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 | nested-application | 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; nested-applications [ nested-application-names ]; nested-application-unknown source-address address <any-unicast>; source-address-range low minimum-value high maximum-value; source-prefix-list list-name; }
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:
then { (accept | discard); (count (application | application-group | application-group-any | nested-application | 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 | 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 thefrom
clause.application-group
—Count the application group that matched in thefrom
clause.application-group-any
—Count all application groups that matchfrom application-group-any
under theany
group name.nested-application
—Count all nested applications that matched in thefrom
clause.none
—Same as not specifyingcount
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