Application QoS on NFX Devices

Understanding Application QoS (AppQoS)

• Benefit of Application QoS

• Unique Forwarding Classes and Queue Assignments

• Application-Aware DSCP Code-Point and Loss Priority Settings

• Rate Limiters and Profiles

• Rate-Limiter Assignment

• Rate-Limiter Action

• AppQoS Security Policy Configuration

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.

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 2³¹ 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 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.

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

• Requirements

• Overview

• Configuration

• Verification

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

Step-by-Step Procedure

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.

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

• Verifying Flow Session Configuration

• Verifying Session Statistics

• Verifying Rate-Limiter Statistics

• Verifying Rule Statistics

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.