Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Class of Service on Services Interfaces

Class of Service Overview

The CoS configuration available for the M Series and MX Series-based service cards enables you to configure Differentiated Services (DiffServ) code point (DSCP) marking and forwarding-class assignment for packets transiting the service cards-service PICs. The M Series and MX Series-based service cards include Multiservices PIC, MS-MIC, MS-MPC, MS-DPC, and Adaptive Services PIC. You can configure the CoS service alongside the stateful firewall and NAT services, using a similar rule structure. The component structures are described in detail in the Class of Service User Guide (Routers and EX9200 Switches).

Standards for Differentiated Services are described in the following documents:

  • RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

  • RFC 2475, An Architecture for Differentiated Services

    Note:

    CoS BA classification is not supported on services interfaces. The CoS configuration is available only for NAT and stateful firewall services. The CoS configuration does not work with other services that run on the service cards such as IPsec.

Restrictions and Cautions for CoS Configuration on Services Interfaces

The following restrictions and cautions apply to CoS configuration on services interfaces:

  • You must configure at least one stateful firewall rule or NAT rule on the service set. Otherwise, CoS does not work.

  • The services interfaces do not support scheduling, only DiffServ marking and queue assignment. You must configure scheduling at the [edit class-of-service] hierarchy level on the output interface or fabric.

  • In the default configuration, queues 1 and 2 receive 0 percent bandwidth. If packets will be assigned to these queues, you must configure a scheduling map.

  • You must issue a commit full command before using custom forwarding-class names in the configuration.

  • Only the Junos standard DiffServ names can be used in the configuration. Custom names are not recognized.

  • On M Series routers, you can configure rewrite rules that change packet headers and attach the rules to output interfaces. These rules might overwrite the DSCP marking configured on a MultiServices PIC. It is important to keep this adverse effect in mind and use care when creating system-wide configurations.

    For example, knowing that the MultiServices PIC can mark packets with any ToS or DSCP value and the output interface is restricted to only eight DSCP values, rewrite rules on the output interface condense the mapping from 64 to 8 values with overall loss of granularity. In this case, you have the following options:

    • Remove the rewrite rules from the output interface.

    • Configure the output interface to include the most important mappings.

Configuring CoS Rules

To configure a CoS rule, include the rule rule-name statement at the [edit services cos] hierarchy level:

Each CoS rule consists of a set of terms, similar to a filter configured at the [edit firewall] hierarchy level. A term consists of the following:

  • from statement—Specifies the match conditions and applications that are included and excluded.

  • then statement—Specifies the actions and action modifiers to be performed by the router software.

Apply the CoS rule to a service set at the [edit services] hierarchy level:

The following sections explain how to configure the components of CoS rules:

Configuring Match Direction for CoS Rules

Each rule must include a match-direction statement that specifies the direction in which the rule match is applied. To configure where the match is applied, include the match-direction statement at the [edit services cos rule rule-name] hierarchy level:

If you configure match-direction input-output, bidirectional rule creation is allowed.

The match direction is used with respect to the traffic flow through the Multiservices PIC, MS-MIC, or MS-MPC. When a packet is sent to the PIC, direction information is carried along with it.

With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.

With a next-hop service set, packet direction is determined by the interface used to route the packet to the Multiservices PIC, MS-MIC, or MS-MPC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the Multiservices PIC, MS-MIC, or MS-MPC, the packet direction is output. For more information on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.

On the Multiservices PIC, MS-MIC, or MS-MPC, a flow lookup is performed. If no flow is found, rule processing is performed. All rules in the service set are considered. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that matches the packet direction are considered.

Configuring Match Conditions In CoS Rules

To configure CoS match conditions, include the from statement at the [edit services cos rule rule-name term term-name] hierarchy level:

The source address and destination address can be either IPv4 or IPv6. You can use either the source address or the destination address as a match condition, in the same way that you would configure a firewall filter; for more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

Alternatively, you can specify a list of source or destination prefixes by configuring the prefix-list statement at the [edit policy-options] hierarchy level and then including either the destination-prefix-list or source-prefix-list statement in the CoS rule. For an example, see Examples: Configuring Stateful Firewall Rules.

If you omit the from term, the router accepts all traffic and the default protocol handlers take effect:

  • User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Control Message Protocol (ICMP) create a bidirectional flow with a predicted reverse flow.

  • IP creates a unidirectional flow.

You can also include application protocol definitions you have configured at the [edit applications] hierarchy level; for more information, see Configuring Application Properties.

  • To apply one or more specific application protocol definitions, include the applications statement at the [edit services cos rule rule-name term term-name from] hierarchy level.

  • To apply one or more sets of application protocol definitions you have defined, include the application-sets statement at the [edit services cos rule rule-name term term-name from] hierarchy level.

    Note:

    If you include one of the statements that specifies application protocols, the router derives port and protocol information from the corresponding configuration at the [edit applications] hierarchy level; you cannot specify these properties as match conditions.

Configuring Actions in CoS Rules

To configure CoS actions, include the then statement at the [edit services cos rule rule-name term term-name] hierarchy level:

The principal CoS actions are as follows:

  • dscp—Causes the packet to be marked with the specified DiffServ code point (DSCP) value or alias.

  • forwarding-class—Causes the packet to be assigned to the specified forwarding class.

For detailed information about DSCP values and forwarding classes, see Examples: Configuring CoS on Services Interfaces or the Class of Service User Guide (Routers and EX9200 Switches).

You can optionally set the configuration to record information in the system logging facility by including the syslog statement at the [edit services cos rule rule-name term term-name then] hierarchy level. This statement overrides any syslog setting included in the service set or interface default configuration.

For information about some additional CoS actions, see the following sections:

Configuring Application Profiles for Use as CoS Rule Actions

You can optionally define one or more application profiles for inclusion in CoS actions. To configure application profiles, include the application-profile statement at the [edit services cos] hierarchy level:

The application-profile statement includes two main components and three traffic types: ftp with the data traffic type and sip with the video and voice traffic types. You can set the appropriate dscp and forwarding-class values for each component within the application profile.

Note:

The ftp and sip statements are not supported on Juniper Network MX Series 3D Universal Edge Routers.

You can apply the application profile to a CoS configuration by including it at the [edit services cos rule rule-name term term-name then] hierarchy level.

Configuring Reflexive, Revert, and Reverse CoS Rule Actions

CoS services are unidirectional. It might be necessary to specify different treatments for flows in opposite directions.

Regardless of whether a packet matches the input, output or input-output direction, flows in both directions are created. A forward, reverse, or forward-and-reverse CoS action is associated with each flow. Bear in mind that the flow in the reverse direction might end up having a CoS action associated with it that you have not specifically configured.

To control the direction in which service is applied, as distinct from the direction in which the rule match is applied, you can configure the (reflexive | revert | reverse) statement at the [edit services cos rule rule-name term term-name then] hierarchy level:

The three actions are mutually exclusive:

  • reflexive causes the CoS rule actions to be applied to flows in the reverse direction as well as to flows in the matching direction.

  • Starting with Junos OS Release 16.1R5 and Junos OS Release 17.4R1, revert stores the DSCP and forwarding class of a packet that is received in the match direction of the rule and then applies that DSCP and forwarding class to packets that are received in the reverse direction of the same session.

  • reverse allows you to define the CoS behavior for flows in the reverse direction.

If you omit the statement, data flows inherit the CoS behavior of the forward control flow.

Configuring CoS Session Creation When Packet Received in Non-Matching Direction

Starting with Junos OS Release 16.1R5 and Junos OS Release 17.4R1, you can configure a service set to create a CoS session even if a packet is first received in the wrong match direction for a CoS rule that is assigned to the service set. This results in the CoS rule values being applied as soon as a packet in the correct match direction is received. To configure this capability, include the match-rules-on-reverse-flow at the [edit services service-set service-set-name cos-options] hierarchy level:

Example: Configuring CoS Rules

The following example shows a CoS configuration containing two rules, one for input matching on a specified application set and the other for output matching on a specified source address:

Configuring CoS Rule Sets

The rule-set statement defines a collection of CoS rules that determine what actions the router software performs on packets in the data stream. You define each rule by specifying a rule name and configuring terms. Then you specify the order of the rules by including the rule-set statement at the [edit services cos] hierarchy level with a rule statement for each rule:

The router software processes the rules in the order in which you specify them in the configuration. If a term in a rule matches the packet, the router performs the corresponding action and the rule processing stops. If no term in a rule matches the packet, processing continues to the next rule in the rule set. If none of the rules matches the packet, the packet is dropped by default.

Examples: Configuring CoS on Services Interfaces

To make settings consistent across Juniper Networks routers, you configure many CoS settings at the [edit class-of-service] hierarchy level to be used on services interfaces. When you commit this configuration along with what you configure at the [edit services cos] hierarchy level, these properties are applied to the Multiservices PIC, MS-MIC, or MS-MPC.

The following configuration examples at the [edit class-of-service] hierarchy level can be applied on services interfaces. For more information, see the Class of Service User Guide (Routers and EX9200 Switches).

Note:

The first two configurations, mapping forwarding-class name to forwarding-class ID and mapping forwarding-class name to queue number, are mutually exclusive.

Mapping Forwarding-Class Name to Forwarding-Class ID

Map forwarding-class names to forwarding-class IDs:

Mapping Forwarding-Class Name to Queue Number

Map forwarding-class names to queue numbers:

Mapping Diffserv Code Point Aliases to DSCP Bits

Map alias names to DSCP bit values. The aliases then can be used instead of the DSCP bits in adaptive services configurations.

Here is an example:

See Also

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
16.1R5
Starting with Junos OS Release 16.1R5 and Junos OS Release 17.4R1, revert stores the DSCP and forwarding class of a packet that is received in the match direction of the rule and then applies that DSCP and forwarding class to packets that are received in the reverse direction of the same session.
16.1R5
Starting with Junos OS Release 16.1R5 and Junos OS Release 17.4R1, you can configure a service set to create a CoS session even if a packet is first received in the wrong match direction for a CoS rule that is assigned to the service set.