Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Class of Service Action in an IDP Policy

 

Class of Service (CoS) or Quality of Service (QoS) is a way to manage multiple traffic profiles over a network by giving certain types of traffic priority over others. For example you can give Voice traffic priority over email or http traffic.

For more information on IDP for CoS, see the following topics:

IDP Class of Service Action Overview

Differentiated Services (DS) is a system for tagging (or “marking”) traffic at a position within a hierarchy of priority. Differentiated Services codepoint (DSCP) marking maps the Junos OS Class of Service (CoS) level to the DSCP field in the IP packet header. On NFX150 devices, DSCP values of IP packets can be rewritten by the following two software modules:

  • Differentiated Services code point (DSCP) rewriter at an egress interface.

  • IDP module according to IDP policies.

In the data plane, before a packet reaches an egress interface, the IDP module can notify the security flow module to rewrite the packet’s DSCP value. The IDP module and the interface-based rewriter rewrite DSCP values based on different and independent rules. The IDP module rewrites a packet’s DSCP value based on IDP policies; whereas the interface-based writer rewrites a packet’s DSCP value based on packet classification results. Therefore the rewriting decisions of the IDP module and the interface-based rewriter can be different.

An interface-based rewriter rewrites DSCP values by comparing a packet’s forwarding class against a set of forwarding classes configured as rewrite rules. A forwarding class that does not belong to this set of forwarding classes is used to notify an interface-based rewriter to not rewrite a packet’s DSCP value when it has been set by the IDP module.

Note

In addition to influencing the rewriting of a packet’s DSCP value, forwarding classes are also used to prioritize the traffic in the device. By assigning a forwarding class to a queue number, you affect the scheduling and marking of a packet as it transits a device. For information on forwarding classes, see Forwarding Classes Overview.

When the IDP module rewrites a packet’s DSCP value, IDP can set the forwarding class associated with the packet such that the forwarding class is out of the set of forwarding classes defined as the rule for an egress interface-based rewriter. For information on rewrite rules, see Rewrite Rules Overview and Example: Configuring and Applying Rewrite Rules on a Security Device.

When the interface-based rewriter processes the packet, it notices that the packet’s forwarding class does not match any of the classes defined in the rewrite rule, therefore it does not change the DSCP value of the packet. Consequently, the packet’s DSCP value is marked by the IDP module and the interface-based rewriter is bypassed. Separate forwarding classes for the IDP module and the interface-based rewriter can be defined using the set forwarding-class statement at the [edit class-of-service] hierarchy level. For example, forwarding classes fc0, fc1, fc2, and fc3 can be defined for the IDP module, while forwarding classes fc4, fc5, fc6, and fc7 can be defined for the interface-based rewriters. In Junos OS, multiple forwarding classes can be mapped to one priority queue. Therefore the number of forwarding classes can be more than the number of queues.

Note

When both the interface-based rewriter and the IDP modules try to rewrite DSCP values, the IDP module is given precedence over the interface-based rewriter because IDP marks DSCP values with more information about the packets and has stricter security criteria than the interface-based rewriter module.

For a configuration example that shows how you can rewrite DSCP values with the IDP module and bypass the interface-based rewriter, see Example: Applying the CoS Action in an IDP Policy.

IDP Class of Service Action Overview

Differentiated Services (DS) is a system for tagging (or “marking”) traffic at a position within a hierarchy of priority. Differentiated Services codepoint (DSCP) marking maps the Junos OS Class of Service (CoS) level to the DSCP field in the IP packet header. On NFX devices, DSCP values of IP packets can be rewritten by the following two software modules:

  • Differentiated Services code point (DSCP) rewriter at an egress interface.

  • IDP module according to IDP policies.

In the data plane, before a packet reaches an egress interface, the IDP module can notify the security flow module to rewrite the packet’s DSCP value. The IDP module and the interface-based rewriter rewrite DSCP values based on different and independent rules. The IDP module rewrites a packet’s DSCP value based on IDP policies; whereas the interface-based writer rewrites a packet’s DSCP value based on packet classification results. Therefore the rewriting decisions of the IDP module and the interface-based rewriter can be different.

An interface-based rewriter rewrites DSCP values by comparing a packet’s forwarding class against a set of forwarding classes configured as rewrite rules. A forwarding class that does not belong to this set of forwarding classes is used to notify an interface-based rewriter to not rewrite a packet’s DSCP value when it has been set by the IDP module.

Note

In addition to influencing the rewriting of a packet’s DSCP value, forwarding classes are also used to prioritize the traffic in the device. By assigning a forwarding class to a queue number, you affect the scheduling and marking of a packet as it transits an NFX device. For information on forwarding classes, see Forwarding Classes Overview.

When the IDP module rewrites a packet’s DSCP value, IDP can set the forwarding class associated with the packet such that the forwarding class is out of the set of forwarding classes defined as the rule for an egress interface-based rewriter. For information on rewrite rules, see Rewrite Rules Overview and Example: Configuring and Applying Rewrite Rules on a Security Device.

When the interface-based rewriter processes the packet, it notices that the packet’s forwarding class does not match any of the classes defined in the rewrite rule, therefore it does not change the DSCP value of the packet. Consequently, the packet’s DSCP value is marked by the IDP module and the interface-based rewriter is bypassed. Separate forwarding classes for the IDP module and the interface-based rewriter can be defined using the set forwarding-class statement at the [edit class-of-service] hierarchy level. For example, forwarding classes fc0, fc1, fc2, and fc3 can be defined for the IDP module, while forwarding classes fc4, fc5, fc6, and fc7 can be defined for the interface-based rewriters. In Junos OS, multiple forwarding classes can be mapped to one priority queue. Therefore the number of forwarding classes can be more than the number of queues.

Note

When both the interface-based rewriter and the IDP modules try to rewrite DSCP values, the IDP module is given precedence over the interface-based rewriter because IDP marks DSCP values with more information about the packets and has stricter security criteria than the interface-based rewriter module.

For a configuration example that shows how you can rewrite DSCP values with the IDP module and bypass the interface-based rewriter, see Example: Applying the CoS Action in an IDP Policy.

Forwarding Classes Overview

Forwarding classes (FCs) allow you to group packets for transmission and to assign packets to output queues. The forwarding class and the loss priority define the per-hop behavior (PHB in DiffServ) of a packet.

Juniper Networks devices support eight queues (0 through 7). For a classifier to assign an output queue (default queues 0 through 3) to each packet, it must associate the packet with one of the following forwarding classes:

  • Expedited forwarding (EF)—Provides a low-loss, low-latency, low-jitter, assured-bandwidth, end-to-end service.

  • Assured forwarding (AF)—Provides a group of values you can define and includes four subclasses—AF1, AF2, AF3, and AF4—each with three drop probabilities (low, medium, and high).

  • Best effort (BE)—Provides no service profile. For the BE forwarding class, loss priority is typically not carried in a class-of-service (CoS) value, and random early detection (RED) drop profiles are more aggressive.

  • Network Control (NC)—This class is typically high priority because it supports protocol control.

In addition to behavior aggregate (BA) and mulitfield (MF) classification, the forwarding class (FC) of a packet can be directly determined by the logical interface that receives the packet. The packet FC can be configured using CLI commands, and if configured, this FC overrides the FC from any BA classification that was previously configured on the logical interface.

The following CLI command can assign an FC directly to packets received at a logical interface:

This section contains the following topics:

Forwarding Class Queue Assignments

Juniper Networks devices have eight queues built into the hardware. By default, four queues are assigned to four FCs. Table 1 shows the four default FCs and queues that Juniper Networks classifiers assign to packets, based on the class-of-service (CoS) values in the arriving packet headers.

Note

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.

By default, all incoming packets, except the IP control packets, are assigned to the FC associated with queue 0. All IP control packets are assigned to the FC associated with queue 3.

Table 1: Default Forwarding Class Queue Assignments

Forwarding Queue

Forwarding Class

Forwarding Class Description

Queue 0

best-effort (BE)

The Juniper Networks device does not apply any special CoS handling to packets with 000000 in the DiffServ field, a backward compatibility feature. These packets are usually dropped under congested network conditions.

Queue 1

expedited-forwarding (EF)

The Juniper Networks device delivers assured bandwidth, low loss, low delay, and low delay variation (jitter) end-to-end for packets in this service class.

Devices accept excess traffic in this class, but in contrast to assured forwarding, out-of-profile expedited-forwarding packets can be forwarded out of sequence or dropped.

Queue 2

assured-forwarding (AF)

The Juniper Networks device offers a high level of assurance that the packets are delivered as long as the packet flow from the customer stays within a certain service profile that you define.

The device accepts excess traffic, but applies a random early detection (RED) drop profile to determine whether the excess packets are dropped and not forwarded.

Three drop probabilities (low, medium, and high) are defined for this service class.

Queue 3

network-control (NC)

The Juniper Networks device delivers packets in this service class with a low priority. (These packets are not delay sensitive.)

Typically, these packets represent routing protocol hello or keepalive messages. Because loss of these packets jeopardizes proper network operation, delay is preferable to discard.

Forwarding Policy Options

CoS-based forwarding (CBF) enables you to control next-hop selection based on a packet’s CoS and, in particular, the value of the IP packet's precedence bits. For example, you can specify a particular interface or next hop to carry high-priority traffic while all best-effort traffic takes some other path. CBF allows path selection based on FC. When a routing protocol discovers equal-cost paths, it can either pick a path at random or load-balance the packets across the paths, through either hash selection or round-robin selection.

A forwarding policy also allows you to create CoS classification overrides. You can override the incoming CoS classification and assign the packets to an FC based on the packets’ input interfaces, input precedence bits, or destination addresses. When you override the classification of incoming packets, any mappings you configured for associated precedence bits or incoming interfaces to output transmission queues are ignored.

Rewrite Rules Overview

A rewrite rule modifies the appropriate class-of-service (CoS) bits in an outgoing packet. Modification of CoS bits allows the next downstream device to classify the packet into the appropriate service group. Rewriting or marking outbound packets is useful when the device is at the border of a network and must alter the CoS values to meet the policies of the targeted peer. A rewrite rule examines the forwarding class and loss priority of a packet and sets its bits to a corresponding value specified in the rule.

Typically, a device rewrites CoS values in outgoing packets on the outbound interfaces of an edge device, to meet the policies of the targeted peer. After reading the current forwarding class and loss priority information associated with the packet, the transmitting device locates the chosen CoS value from a table, and writes this CoS value into the packet header.

Example: Configuring and Applying Rewrite Rules on a Security Device

This example shows how to configure and apply rewrite rules for a device.

Requirements

Before you begin, create and configure the forwarding classes.

Overview

You can configure rewrite rules to replace CoS values on packets received from the customer or host with the values expected by other devices. You do not have to configure rewrite rules if the received packets already contain valid CoS values. Rewrite rules apply the forwarding class information and packet loss priority used internally by the device to establish the CoS value on outbound packets. After you configure rewrite rules, you must apply them to the correct interfaces.

In this example, you configure the rewrite rule for DiffServ CoS as rewrite-dscps. You specify the best-effort forwarding class as be-class, expedited forwarding class as ef-class, an assured forwarding class as af-class, and a network control class as nc-class. Finally, you apply the rewrite rule to an IRB interface.

Note

You can apply one rewrite rule to each logical interface.

Table 2 shows how the rewrite rules replace the DSCPs on packets in the four forwarding classes.

Table 2: Sample rewrite-dscps Rewrite Rules to Replace DSCPs

mf-classifier Forwarding Class

For CoS Traffic Type

rewrite-dscps Rewrite Rules

be-class

Best-effort traffic—Provides no special CoS handling of packets. Typically, RED drop profile is aggressive and no loss priority is defined.

Low-priority code point: 000000

High-priority code point: 000001

ef-class

Expedited forwarding traffic—Provides low loss, low delay, low jitter, assured bandwidth, and end-to-end service. Packets can be forwarded out of sequence or dropped.

Low-priority code point: 101110

High-priority code point: 101111

af-class

Assured forwarding traffic—Provides high assurance for packets within the specified service profile. Excess packets are dropped.

Low-priority code point: 001010

High-priority code point: 001100

nc-class

Network control traffic—Packets can be delayed, but not dropped.

Low-priority code point: 110000

High-priority code point: 110001

Note

Forwarding classes can be configured in a DSCP rewriter and also as an action of an IDP policy to rewrite DSCP code points. To ensure that the forwarding class is used as an action in an IDP policy, it is important that you do not configure an IDP policy and interface-based rewrite rules with the same forwarding class.

Configuration

CLI Quick Configuration

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, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from the configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure and apply rewrite rules for a device:

  1. Configure rewrite rules for DiffServ CoS.
  2. Configure best-effort forwarding class rewrite rules.
  3. Configure expedited forwarding class rewrite rules.
  4. Configure an assured forwarding class rewrite rules.
  5. Configure a network control class rewrite rules.
  6. Apply rewrite rules to an IRB interface.

Results

From configuration mode, confirm your configuration by entering the show class-of-service command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Verification

Verifying Rewrite Rules Configuration

Purpose

Verify that rewrite rules are configured properly.

Action

From configuration mode, enter the show class-of-service command.

user@host> show class-of-service

Meaning

Rewrite rules are configured on IRB interface as expected.

Example: Applying the CoS Action in an IDP Policy

As packets enter or exit a network, devices might be required to alter the CoS settings of the packet. Rewrite rules set the value of the CoS bits within the packet’s header. In addition, you often need to rewrite a given marker (for example, DSCP) at the inbound interfaces of a device to accommodate BA classification by core devices.

On Juniper Network devices, DSCP values of IP packets can be rewritten by the following two software modules:

  • DSCP rewriter at an egress interface

  • IDP module according to IDP policies

This example describes how to create an IDP policy that defines a forwarding class as an action item to rewrite the DSCP value of a packet.

Requirements

Before you begin, review the CoS components.

Overview

This example shows how you can rewrite DSCP values with the IDP module and bypass the interface-based rewriter. When you create an IDP policy to rewrite DSCP values, you must specify the following:

  • Configure separate forwarding classes for the IDP module and the interface-based rewriters. In this example, eight forwarding classes, fc1 through fc8, are configured. Out of these eight forwarding classes, four classes, fc1 through fc4, are assigned to interface-based rewriters; the other four, fc5 through fc8, are assigned to the IDP module. These eight forwarding classes are mapped to four priority queues, queue 0 through queue 3.

  • Configure the DSCP rewriter (rw_dscp) with forwarding classes, fc1 through fc4.

  • Configure a DSCP classifier (c1) with the same forwarding classes as the DSCP rewriter. Essentially the classifier provides inputs, forwarding classes, and loss priorities to the rewriter.

  • Apply the DSCP rewriter, rw_dscp, to a logical interface, ge-0/0/5.

  • Apply the classifier, c1, to an ingress logical interface, ge-0/0/6.

  • Create a new IDP policy (cos-policy) and assign class-of-service forwarding-class fc5 as the action.

    Note

    To ensure DSCP rewriting by IDP, it is important that you do not configure an IDP policy and interface-based DSCP rewrite rules with the same forwarding class.

Configuration

CLI Quick Configuration

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, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Modein the CLI User Guide.

To configure an IDP policy that uses a forwarding class as a notification action for DSCP rewriting, perform the following tasks:

  1. Configure forwarding classes.

    To configure a one-to-one mapping between the eight forwarding classes and the four priority queues, include the following statements at the [edit class-of-service] hierarchy level:

  2. Configure a DSCP rewriter with forwarding classes.
  3. Configure a BA classifier with the same forwarding classes as the DSCP rewriter.
  4. Apply the rewriter to a logical interface.
  5. Apply the classifier to a logical interface.
  6. Configure the IDP policy with the action of forwarding class.

    The following steps show how an IDP policy includes a class-of-service forwarding class as one of the actions. In policy cos-policy, forwarding class fc5 is defined as an action in conjunction with the action of dscp-code-point 62, which requires the IDP module to rewrite DSCP values to 62. Taking actions of R1, the IDP module conducts the security flow module to rewrite the packets’ DSCP values as 62 and set their forwarding classes as fc5.

    To set a forwarding class as one of the actions in an IDP policy, perform the following tasks:

    1. Create a policy by assigning a meaningful name to it.
    2. Associate a rulebase with the policy.
    3. Add rules to the rulebase.
    4. Define the match criteria for the rule.
    5. Define an attack as match criteria.
    6. Specify forwarding class as an action for the rule.
    7. Specify dscp–code-point as an action for the rule.
    8. Specify notification and logging options for the rule.
    9. Set the severity level for the rule.
    10. Activate the policy.

Results

From configuration mode, confirm your configuration by entering the show security idp and show class-of-service commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying IDP Policy Configuration

Purpose

Verify that the forwarding class fc5 is configured as an action in the IDP policy.

Action

From operational mode, enter the show security idp idp-policy cos-policy command.

Verifying CoS Configuration

Purpose

Verify if the one-to-one mapping between the eight forwarding classes and the four priority queues, application of the BA classifier to the interfaces, and the rewrite rule are working.

Action

From operational mode, enter the show class-of-service command.