Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Application QoS on NFX Devices


Application quality of service (AppQoS) enables you to identify and control access to specific applications and provides the granularity of the stateful firewall rule base to match and enforce QoS at the application layer. For more information, see the following topics:

Understanding Application QoS (AppQoS)

The application quality of service (AppQoS) feature expands the capability of Junos OS class of service (CoS) to include marking DSCP values based on Layer-7 application types, honoring application-based traffic through loss priority settings, and controlling transfer rates on egress PICs based on Layer-7 application types.

There are four ways to mark DSCP values on a device:

  • IDP attack action-based DSCP rewriters

  • Layer 7 application-based DSCP rewriters

  • ALG-based DSCP rewriters

  • Firewall filter-based DSCP rewriters

IDP remarking is conducted at the ingress port based on IDP rules. Application remarking is conducted at the egress port based on application rules. Interface-based remarking also occurs at the egress port based on firewall filter rules. (See the Class of Service Feature Guide for Security Devices for a detailed description of Junos OS CoS features.)

The remarking decisions of these three rewriters can be different. If a packet triggers all three, the method that takes precedence is based on how deep into the packet content the match is conducted. IDP remarking has precedence over application remarking which has precedence over interface-based remarking.

If a packet triggers both AppQoS and ALG-based DSCP rewriters, then AppQoS takes precedence over ALG-based DSCP rewriters.

The AppQoS DSCP rewriter conveys a packet’s quality of service through both the forwarding class and a loss priority. The AppQoS rate-limiting parameters control the transmission speed and volume for its associated queues.

Benefit of Application QoS

AppQoS provides the ability to prioritize and meter the application traffic to provide better service to business-critical or high-priority application traffic.

Unique Forwarding Classes and Queue Assignments

The forwarding class provides three functions:

  • Groups packets with like characteristics

  • Assigns output queues

  • Resolves conflicts with existing Junos OS firewall filter-based rewriters

Unique forwarding class names protect AppQoS remarking from being overwritten by interface-based rewrite rules. A firewall filter-based rewriter remarks a packet’s DSCP value if the packet’s forwarding class matches a class defined specifically for this rewriter. If the packet’s forwarding class does not match any of the firewall filter-based rewriter’s classes, the DSCP value is not remarked. To protect AppQoS values from being overwritten, therefore, use forwarding class names that are unknown to the firewall filter-based rewriter.

Each forwarding class is assigned to an egress queue that provides the appropriate degree of enhanced or standard processing. Many forwarding classes can be assigned to a single queue. Therefore, any queues defined for the device can be used by IDP, AppQoS, and firewall filter-based rewriters. It is the forwarding class name, not the queue, that distinguishes the transmission priority. (See the Class of Service Feature Guide for Security Devices for information about configuring queues and schedulers.)

The AppQoS forwarding class names and queue assignments are defined with the class-of-service CLI configuration command:

Application-Aware DSCP Code-Point and Loss Priority Settings

For AppQoS, traffic is grouped based on rules that associate a defined forwarding class with selected applications. The match criteria for the rule includes one or more applications. When traffic from a matching application encounters the rule, the rule action sets the forwarding class, and remarks the DSCP value and loss priority to values appropriate for the application.

A Differentiated Services (DiffServ) code point (DSCP) value is specified in the rule either by a 6-bit bitmap value or by a user-defined or default alias. Table 1 provides a list of Junos OS default DSCP alias names and bitmap values.

Table 1: Standard CoS Aliases and Bit Values

CoS Value Type


Bit Value

Expedited forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Assured forwarding



Best effort


















Network control



Network control



The queue’s scheduler uses the loss priority to control packet discard during periods of congestion by associating drop profiles with particular loss priority values. (See the Class of Service Feature Guide for Security Devices for information about configuring queues and schedulers.)

The rule applies a loss priority to the traffic groups. A high loss priority means a high probability that the packet could be dropped during a period of congestion. Four levels of loss priority are available:

  • high

  • medium-high

  • medium-low

  • low

The rule set is defined in the class-of-service application-traffic-control configuration command:

Rate Limiters and Profiles

When congestion occurs, AppQoS implements rate limiting on all egress PICs on the device. If packets exceed the assigned limitations, they are dropped. Rate limiters maintain a consistent level of throughput and packet loss sensitivity for different classes of traffic. All egress PICs employ the same rate-limiting scheme.

The total bandwidth of a PIC is about 10 Gbps. Rate-limiter hardware for the PIC can provision up to 2 Gbps. Therefore, the upper bandwidth limit for rate limiting is 231 bps.

A rate-limiter profile defines the limitations. It is a unique combination of bandwidth-limit and burst-size-limit specifications. The bandwidth-limit defines the maximum number of kilobits per second that can traverse the port. The burst-size-limit defines the maximum number of bytes that can traverse the port in a single burst. The burst-size-limit reduces starvation of lower priority traffic by ensuring a finite size for each burst.

AppQoS allows up to 16 profiles and up to 1000 rate limiters per device. Multiple rate limiters can use the same profile. In the following example, five rate limiters are defined using two profiles:

Rate Limiter Name



















Rate limiters are defined with the class-of-service application-traffic-control configuration command.

Rate-Limiter Assignment

Rate limiters are applied in rules based on the application of the traffic. Two rate limiters are applied for each session: client-to-server and server-to-client. This usage allows traffic in each direction to be provisioned separately.

Different AppQoS rules within the same rule set can share a rate limiter. In this case, the applications of those rules share the same bandwidth. There are no limitations on the number of rules in one rule set that can assign the same rate limiter.

The following examples show how the rate limiters defined in the preceding section could be assigned. For instance, a rule set could reuse a rate limiter in several rules and in one or both flow directions:

  • rule-set-1

    • rule-1A

      • client-to-server limiter-1

      • server-to-client limiter-1

    • rule-1B

      • client-to-server limiter-1

      • server-to-client limiter-1

If the same profiles are needed in several rule sets, a sufficient number of rate limiters needs to be defined specifying the same bandwidth-limit and burst-size-limit. The two rule sets in the following example implement the same profiles by assigning different, but comparable, rate limiters.

  • rule-set-2

    • rule-2A

      • client-to-server limiter-2

      • server-to-client limiter-2

    • rule-2B

      • client-to-server limiter-2

      • server-to-client limiter-4

  • rule-set-3

    • rule-3A

      • client-to-server limiter-3

      • server-to-client limiter-3

    • rule-3B

      • client-to-server limiter-3

      • server-to-client limiter-5

A rate limiter is applied using the class-of-service application-traffic-control rule-sets command in the same way that a forwarding class, DSCP value, and loss priority are set.

If AppQoS and firewall filter-based rate limiting are both implemented on the egress PIC, both are taken into consideration. AppQoS rate limiting is considered first. Firewall filter-based rate limiting occurs after that.


If packets are dropped from a PIC, the device does not send notifications to the client or the server. The upper-level applications on the client and the server devices are responsible for retransmission and error handling.

Rate-Limiter Action

Based on the type of the device, AppQoS rules can be configured with different rate-limiter actions:

  • Discard

    • When this option is selected, the out-of-profile packets are just dropped.

    • This is the default action type and need not be configured.

    • This option is supported on all devices.

  • Loss-priority-high

    • When this option is selected , it elevates the loss priority to maximum. In other words, it is a delayed drop; that is, the discard decision is taken at the egress output queue level. If there is no congestion, it allows the traffic even with maximum loss priority. But if congestion occurs, it drop these maximum loss priority packets first.

    • This option must be configured within the AppQoS rule (to override the default action) using the following command:

AppQoS Security Policy Configuration

The AppQoS rule set can be implemented in an existing policy or a specific application policy.

Example: Configuring AppQoS

This example shows how to enable AppQoS prioritization and rate limiting within a policy.


No special configuration beyond device initialization is required before configuring this feature.


In this example, AppQoS is implemented so that FTP applications are restricted to a level below the specified throughput while other applications are transmitted at a more conventional speed and loss priority level.


We recommend using CLI for configuration of AppSecure features.


Step-by-Step Procedure

To configure an AppQoS implementation:

  1. Define one or more forwarding classes dedicated to AppQoS marking. In this example, a single forwarding class, my-app-fc, is defined and assigned to queue 0.
  2. Define rate limiters. In this example, two rate limiters are defined.Note

    You can define up to 1000 rate limiters for a device, but only 16 profiles (unique bandwidth-limit and burst-size-limit combinations).

    • test-r1 with a bandwidth of 100 Kbps and a burst limit of 13,000 bytes

    • test-r2 with a bandwidth of 200 Kbps and a burst limit of 26,000 bytes

  3. Define AppQos rules and application match criteria. For this example, rule 0 in rule set ftp-test1 is applied to junos:FTP packets.
  4. Define the action for rule 0 when it encounters a junos:FTP packet. In this example, when a match is made, the packet is marked with the forwarding class my-app-fc, the DSCP value of af22, and a loss priority of low.
  5. Assign rate limiters for rule 0 to traffic in each direction. In this case, the rate limiter test-r1 is set in both directions.Note

    Rate limiter test-r1 can be assigned to one or both traffic directions in rule 0. It could also be assigned in other rules within rule set ftp-test1. However, once test-r1 is assigned to rule set ftp-test1, it cannot be assigned in any other rule set.

  6. Log the AppQoS event whenever this action is triggered:
  7. Define other rules to handle application packets that did not match the previous rule. In this example, a second and final rule applies to all remaining applications.
  8. Assign rate limiters for the second rule. In this example, any traffic that is not from FTP is assigned rate limiter test-r2 in both directions.
  9. Add the AppQoS implementation to a policy. In this example, policy p1 applies the rule set ftp-test1 to all traffic from the trust zone to the untrust zone.


From configuration mode, confirm your policy configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

If you are done configuring the device, enter commit from configuration mode.


Confirm that the configuration is working properly.

Verifying Flow Session Configuration


Verify that AppQoS is enabled.


From operational mode, enter the show security flow session application-traffic-control extensive command.


The entry for application traffic control identifies the rule set and rule of the current session.

Verifying Session Statistics


Verify that AppQoS session statistics are being accumulated at each egress node.


From operational mode, enter the show class-of-service application-traffic-control counter command.


The AppQoS statistics are maintained only if application-traffic-control service is enabled. The number of sessions processed, marked, and honored show that sessions are being directed based on configured AppQoS features. The rate-limiting statistics count the number of directional session flows that have been rate limited.

Verifying Rate-Limiter Statistics


Verify that bandwidth is being limited as expected when the FTP application is encountered.


From operational mode, enter the show class-of-service application-traffic-control statistics rate-limiter command.


Real-time application bandwidth-limit information for each PIC is displayed by rule set. This command provides an indication of the applications being rate limited and the profile being applied.

Verifying Rule Statistics


Verify that the rule matches the rule statistics.


From operational mode, enter the show class-of-service application-traffic-control statistics rule command.


This command provides information on the number of (session) hits for a rule under each rule set.