Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Firewall Filter Terminating and Nonterminating Actions for Protocol-Independent Traffic in Dynamic Service Profiles

Firewall filters in dynamic service profiles support a set of terminating actions that halt all evaluation of a firewall filter for a specific packet. The router performs the specified action, and no additional terms are examined. Table 1 describes the terminating actions conditions that are supported for protocol-independent traffic—that is, configured under family any—for filters in dynamic service profiles.

Note:

You cannot configure the next action with a terminating action in the same filter term. However, you can configure the next action with another nonterminating action in the same filter term.

Note:

Protocol-independent firewall filters in dynamic service profiles are supported only on MX Series routers with MPCs.

Table 1: Terminating Actions for Firewall Filters for Protocol-Independent Traffic in Dynamic Service Profiles

Terminating Action

Description

accept

Accept the packet.

discard

Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message. Discarded packets are available for logging and sampling.

Firewall filters in dynamic service profiles also support a set of nonterminating actions that are performed for a specific packet before the packet is passed to any subsequent actions in the term. Table 1 describes the terminating actions conditions that are supported for protocol-independent traffic—that is, configured under family any—for filters in dynamic service profiles.

Table 2: Nonterminating Actions for Firewall Filters for Protocol-Independent Traffic in Dynamic Service Profiles

Nonterminating Action

Description

count counter-name

Count the packet in the named counter.

force-premium

By default, a hierarchical policer processes the traffic it receives according to the traffic’s forwarding class. Premium, expedited-forwarding traffic, has priority for bandwidth over aggregate, best-effort traffic. The force-premium filter ensures that traffic matching the term is treated as premium traffic by a subsequent hierarchical policer, regardless of its forwarding class. This traffic is given preference over any aggregate traffic received by that policer.

Note:

The force-premium filter option is supported only on MPCs.

forwarding-class class-name

Classify the packet to the named forwarding class:

  • forwarding-class-name

  • assured-forwarding

  • best-effort

  • expedited-forwarding

  • network-control

Note:

This action is supported on ingress only.

hierarchical-policer

Police the packet using the specified hierarchical policer.

loss-priority (high | medium-high | medium-low | low)

Set the packet loss priority (PLP) level.

You cannot also configure the three-color-policer nonterminating action for the same firewall filter term. These two nonterminating actions are mutually exclusive.

You must include the tri-color statement at the [edit class-of-service] hierarchy level to commit a PLP configuration with any of the four levels specified. If the tri-color statement is not enabled, you can configure only the high and low levels. This applies to all protocol families.

For information about the tri-color statement, see Configuring and Applying Tricolor Marking Policers. For information about using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see Understanding How Forwarding Classes Assign Classes to Output Queues.

For information about the tri-color statement and using behavior aggregate (BA) classifiers to set the PLP level of incoming packets, see Understanding How Behavior Aggregate Classifiers Prioritize Trusted Traffic.

Note:

This action is supported on ingress only.

next

Proceed to the next filter term.

policer policer-name

Name of policer to use to rate-limit traffic.

port-mirror

instance-name

Port-mirror the packet based on the specified family.

Note:

This action is supported on ingress only.

service-accounting

Use the inline counting mechanism when capturing subscriber per-service statistics.

Count the packet for service accounting. The count is applied to a specific named counter (__junos-dyn-service-counter) that RADIUS can obtain.

The service-accounting and service-accounting-deferred keywords are mutually exclusive, both per-term and per-filter.

Note:

This action is not supported on T4000 Type 5 FPCs and PTX Series Packet Transport Routers.

service-accounting- deferred

Use the deferred counting mechanism when capturing subscriber per-service statistics. The count is applied to a specific named counter (__junos-dyn-service-counter) that RADIUS can obtain.

The service-accounting and service-accounting-deferred keywords are mutually exclusive, both per-term and per-filter.

Note:

This action is not supported on T4000 Type 5 FPCs and PTX Series Packet Transport Routers.

service-filter-hit

(Only if the service-filter-hit flag is marked by a previous filter in the current type of chained filters) Direct the packet to the next type of filters.

Indicate to subsequent filters in the chain that the packet was already processed. This action, coupled with the service-filter-hit match condition in receiving filters, helps to streamline filter processing.

Note:

This action is not supported on T4000 Type 5 FPCs and PTX Series Packet Transport Routers.

three-color-policer (single-rate | two-rate) policer-name

Police the packet using the specified single-rate or two-rate three-color-policer.

Note:

You cannot also configure the loss-priority action for the same firewall filter term. These two actions are mutually exclusive.