Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Application QoS

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

Understanding Application Quality of Service (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 the security 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 User Guide (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 User Guide (Security Devices) for information about configuring queues and schedulers.)

For SRX5400, SRX5600, and SRX5800 devices, the AppQoS forwarding class names and queue assignments are defined with the class-of-service CLI configuration command:

For SRX300, SRX320, SRX340, SRX345, SRX380, SRX550M, SRX1500, SRX4100, SRX4200, and SRX4600 devices and vSRX Virtual Firewall instances, 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

Alias

Bit Value

ef

101110

af11

001010

af12

001100

af13

001110

af21

010010

af22

010100

af23

010110

af31

011010

af32

011100

af33

011110

af41

100010

af42

100100

af43

100110

be

000000

cs1

001000

cs2

010000

cs3

011000

cs4

100000

cs5

101000

nc1/cs6

110000

nc2/cs7

111000

See Default CoS Values and Aliases for more details.

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 User Guide (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

Profile

bandwidth-limit

burst-size-limit

limiter-1

200

26000

limiter-2

200

26000

limiter-3

200

26000

limiter-4

400

52000

limiter-5

400

52000

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.

The processing of traffic bandwidth by rate limiters is done at the packet level regardless of the direction of traffic. For example: Consider a case where you have only one rate limiter of 10G configured, if the ingress and egress traffic is from the same line card, then the throughput (maximum traffic of both ingress and egress directions combined) can only be up to 10G and not 20G. However, if the device has IOC support (in case of SRX5000 line devices and SRX4600 devices) and ingress traffic is through one IOC and egress traffic through other IOC, then with a single rate-limiter of 10G configured, you can expect a throughput of 20G.

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

Note:

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 security 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 SRX Series Firewalls.

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

    • This option is supported only on for SRX300, SRX320, SRX340, SRX345 devices.

AppQoS Security Policy Configuration

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

Example: Configuring Application Quality of Service

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

Requirements

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

Overview

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.

Configuration

Procedure

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

To configure an AppQoS on your security device:

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

    For SRX5400, SRX5600, and SRX5800 devices, use the set class-of-service forwarding-classes class my-app-fc queue 4 command.

    Juniper Networks devices support eight queues (0 to 7). The default queues 0 through 3 are assigned to default forwarding classes. Queues 4 through 7 have no default assignments to FCs and are not mapped. To use queues 4 through 7, you must create custom FC names and map them to the queues. For more details, see Forwarding Classes Overview.

  2. Define rate limiters. In this example, two rate limiters are defined.

    For SRX5400, SRX5600, and SRX5800 devices, you can define up to 1000 rate limiters for a device, but only 16 profiles (unique bandwidth-limit and burst-size-limit combinations).

  3. Define AppQos rules and application match criteria.

    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. We've assigned same rate limiter on both the directions.

    You can assign a rate limiter to one or both traffic directions in a single rule. You can also assign a same rate limiter to other rules within a rule set. However, you cannot assign a same rate limiter to different rule set.

  4. Define another rule to handle application packets that did not match the previous rule. In this example, a second and final rule applies to all remaining applications.

  5. Add the AppQoS setting to the security policy.

Results

From configuration mode, confirm your policy configuration by entering the show security policies and show class-of-service 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.

Verification

Confirm that the configuration is working properly.

Verifying Flow Session Configuration

Purpose

Verify that AppQoS is enabled.

Action

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

Meaning

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

Verifying Session Statistics

Purpose

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

Action

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

Meaning

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

Purpose

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

Action

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

Meaning

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

Purpose

Verify that the rule matches the rule statistics.

Action

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

Meaning

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

Application Quality of Service Support for Unified Policies

Starting in Junos OS Release 18.2R1, SRX Series Firewalls and vSRX Virtual Firewall instances support unified policies, allowing granular control and enforcement of dynamic Layer 7 applications within the traditional security policy.

Unified policies are the security policies that enable you to use dynamic applications as part of the existing 5-tuple or 6-tuple (5-tuple with a user firewall) match conditions to detect application changes over time.

Application quality of service (AppQoS) is supported when the security device is configured with unified policies. You can configure a default AppQoS rule set to manage unified policy conflicts if multiple security policies match the traffic.

AppQoS rule sets are included in the unified policy to implement application-aware quality-of-service control. You can configure a rule set with rules under the application-traffic-control option, and attach the AppQoS rule set to a unified security policy as an application service. If the traffic matches the specified dynamic application and the policy action is permit, the application-aware quality of service is applied.

Note the following AppQoS functionality in unified policies:

  • Upgrading from traditional security policy to a unified policy—In a unified policy, when you configure the dynamic-application option as none, the AppQoS rule set is applied during the security policy match and the AppQoS looks for the corresponding rule for the identified traffic. This is the same behavior for AppQoS functionality in Junos OS releases prior to Release 18.2R1.

  • AppQoS rule with a unified policy—In the application traffic control configuration, the AppQoS rule set is configured with the match condition as application-any and in the unified policy, a specific dynamic application is used as the match condition, then, the AppQoS functionality works according to the rule in the unified policy.

Understanding Default Application Quality of Service Rule Set for Unified Policies

You can configure an AppQoS default rule set to manage security policy conflicts.

The initial policy lookup phase occurs prior to identifying a dynamic application. If there are multiple policies present in the potential policy list that contain different AppQoS rule sets, then the security device applies the default AppQoS rule set until a more explicit match has occurred.

You can set an AppQoS as a default AppQoS rule set under the edit security ngfw hierarchy level. The default AppQoS rule set is leveraged from one of the existing AppQoS rule sets, which are configured under the [edit class-of-service application-traffic-control] hierarchy level.

Table 2 summarizes the usage of the default AppQoS rule set under different scenarios in a unified policy.

Table 2: AppQoS Rule Set Usage in Unified Policies

Application Identification Status

AppQoS Rule Set Usage

Action

No security policy conflict.

The AppQoS rule set under the [edit class-of-service application-traffic-control] hierarchy is applied when the traffic matches the security policy.

AppQoS is applied as in the AppQoS rule set.

Security policy conflict and conflicting polices have distinct AppQoS rule sets.

The default AppQoS rule set is not configured or is not found.

Session is ignored because the default AppQoS profile is not configured.

As a result, even if the final matched policy in the policy conflict scenario has an AppQoS rule set, this rule set is not applied. We recommend configuring a default AppQoS rule set to manage security policy conflicts.

The default AppQoS rule set is configured.

AppQoS is applied as in the default AppQoS rule set.

Final application is identified

The matching security policy has an AppQoS rule set, which is same as the default AppQoS rule set.

AppQoS is applied as in the default AppQoS rule set.

The matching security policy does not have an AppQoS rule set.

Default AppQoS rule set is not applied and AppQoS is not applied for the session.

The Matching security policy has an AppQoS rule set different from the default AppQoS rule set, which is already applied.

Default AppQoS rule set remains as the default AppQoS rule set.

When a default AppQoS rule set is applied on the traffic and the final security policy has a different AppQoS rule set, in such cases switching from the default AppQoS rule set to the AppQoS rule set in the final security policy is not supported.

Default Application Quality of Service Rule Set In Different Scenarios

The following links are to examples that discuss the default AppQoS rule sets in different scenarios:

Table 3 shows different AppQoS rule sets that are configured for unified policies with dynamic applications as the match condition.

Table 3: Different AppQoS Rule Sets in Unified Policies

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

AppQoS Rule Set

Policy-P1

S1

50.1.1.1

D1

Any

Any

Any

Facebook

AppQoS

AppQoS-1

Policy-P2

S1

50.1.1.1

D1

Any

Any

Any

Google

AppQoS

AppQoS-2

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

AppQoS

AppQoS-3

In this example, any AppQoS rule sets (AppQoS-1, AppQoS-2, AppQoS-3) can be configured as a default AppQoS rule set under the [security ngfw] hierarchy level. It is not necessary for a default rule set to be part of a security policy configuration. Any AppQoS rule set under the [edit class-of-service application-traffic-control] hierarchy level can be assigned as the default AppQoS rule set.

No Policy Conflict—All Policies Have the Same AppQoS Rule Set

All matching policies have the same AppQoS rule set as shown in Table 4.

Table 4: All Matching Policies Have Same AppQoS Rule Sets

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

AppQoS Rule Set

Policy-P1

S1

Any

D1

Any

Any

Any

Facebook

AppQoS

AppQoS-1

Policy-P2

S1

Any

D1

Any

Any

Any

Google

AppQoS

AppQoS-1

In this scenario, the policies Policy-P1 and Policy-P2 have the same AppQoS rule set; that is, AppQoS-1. The rule set AppQoS-1 is applied. Policy-P3 is not configured in this scenario.

If you have configured the rule set AppQoS-2 as the default rule set, it is not applied. That’s because there is no conflict in the AppQoS rule sets in the conflicted policies (Policy-P1 and Policy-P2).

No Policy Conflict—All Policies Have the Same AppQoS Rule Set and the Final Policy Has No AppQoS Rule Set

All matching policies have the same AppQoS rule set as shown in Table 5 and the final policy has no AppQoS rule set.

Table 5: All Matching Policies Have Same AppQoS Rule Sets and the Final Policy Has No AppQoS Rule Set

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

AppQoS Rule Set

Policy-P1

S1

Any

D1

Any

Any

Any

Facebook

AppQoS

AppQoS-1

Policy-P2

S1

Any

D1

Any

Any

Any

Google

AppQoS

AppQoS-1

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

Other

None

In this scenario, both Policy-P1 and Policy-P2 have the same AppQoS rule set, that is, AppQoS-1. In this case, the rule set AppQoS-1 is applied.

When the final policy Policy-P3 is matched, AppQoS ignores the session, because the AppQoS rule set is not configured for Policy-P3.

If the final security policy does not have any AppQoS rule set, then AppQoS is not applied on the traffic. All AppQoS settings that are applied in the prematch stage are reverted to the original values.

Policy Conflict—No AppQoS Rule Set is Configured for the Final Policy

The default AppQoS rule set (in this scenario AppQoS-1) is applied during the potential policy match as shown in Table 6. The final policy Policy-P3 has no AppQoS rule set.

Table 6: Matching Policies Have Different AppQoS Rule Sets and the Final Policy Has No AppQoS Rule Set

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

AppQoS Rule Set

Policy-P1

S1

50.1.1.1

D1

Any

Any

Any

Facebook

AppQoS

AppQoS-1

Policy-P2

S1

50.1.1.1

D1

Any

Any

Any

Google

AppQoS

AppQoS-2

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

Other

NA

AppQoS ignores the session if the final matching policy Policy-P3 is applied.

If the final security policy does not have any AppQoS rule set, then AppQoS is not applied on the traffic. In this case, all AppQoS settings that are applied in the prematch stage are reverted to the original values.

Policy Conflict—Default AppQoS Rule Set and a Different AppQoS Rule Set for the Final Policy

The rule set AppQoS-1 is configured as a default rule set and is applied when the final application is not yet identified. The final policy Policy-P3 has a different AppQoS rule set (AppQoS-3) as shown in Table 7.

Table 7: Different AppQoS Rule Set for the Final Policy

Security Policy

Source Zone

Source IP Address

Destination Zone

Destination IP Address

Port Number

Protocol

Dynamic Application

Service

AppQoS Rule Set

Policy-P1

S1

50.1.1.1

D1

Any

Any

Any

Facebook

AppQoS

AppQoS-1

Policy-P2

S1

50.1.1.1

D1

Any

Any

Any

Google

AppQoS

AppQoS-2

Policy-P3

S1

50.1.1.1

D1

Any

Any

Any

YouTube

AppQoS

AppQoS-3

When the final application is identified, the policy Policy-P3 is matched and applied. In this case, the rule set AppQoS-3 is not applied. Instead the rule set AppQoS-1 is applied as the default rule set and remains as the default rule set.

Limitation of AppQoS with Unified Policies

When a security policy is applied to the matching traffic, the AppQoS rule set is applied to the permitted traffic. If the security policy and the applied AppQoS rule set have different dynamic applications, then a conflict might occur as shown in the following example:

In this example, the application traffic control rule is configured for junos:GOOGLE and the security policy match condition for the dynamic application is junos: FTP. In such cases, conflicts might occur when the final policy is applied.

Example: Configuring Application Quality of Service with Unified Policy

This example shows how to enable application quality of service (AppQoS) within a unified policy to provide prioritization and rate limiting for the traffic.

Requirements

This example uses the following hardware and software components:

  • SRX Series Firewall running Junos OS Release 18.2R1 and later. This configuration example is tested for Junos OS Release 18.2R1.

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

Overview

In this example, you configure an AppQoS rule set and invoke AppQoS as an application service in the security policy for the Facebook application.

You define a default AppQoS rule set under the [edit security ngfw] hierarchy level to manage security policy conflicts, if any.

Configuration

Procedure

Step-by-Step Procedure

To configure AppQoS with a unified policy:

  1. Define an AppQoS rule set.

  2. Configure a default AppQoS rule set. Select the rule set RS1 that is created under the application traffic control as the default AppQoS rule set.

  3. Associate the class-of-service rule set to the unified policy.

Results

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.

Verification

Confirm that the configuration is working properly.

Verifying Flow Session Configuration

Purpose

Display AppQoS session statistics.

Action

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

Sample Output
command-name
Meaning

The output displays the number of sessions processed, marked, and honored. The rate-limiting statistics count the number of directional session flows that have been rate limited.

Verifying Rule Statistics

Purpose

Display the AppQoS rule statistics.

Action

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

Meaning

The output provides information on the number of sessions matched for the rule under each AppQoS rule set.