Understanding CoS Forwarding Classes
Forwarding classes group traffic and assign the traffic to output queues. Each forwarding class is mapped to an output queue. Classification maps incoming traffic to forwarding classes based on the code point bits in the packet or frame header. Forwarding class to queue mapping defines the output queue used for the traffic classified into a forwarding class.
Except on NFX Series devices, a classifier must associate each packet with one of the following four (QFX10000 switches) or five (other switches) default forwarding classes or with a user-configured forwarding class to assign an output queue to the packet:
fcoe—Guaranteed delivery for Fibre Channel over Ethernet (FCoE) traffic.
no-loss—Guaranteed delivery for TCP lossless traffic.
best-effort—Provides best-effort delivery without a service profile. Loss priority is typically not carried in a class-of-service (CoS) value.
network-control—Supports protocol control and is typically high priority.
mcast—(Except QFX10000) Delivery of multidestination (multicast, broadcast, and destination lookup fail) packets.
On NFX Series devices, a classifier must associate each packet with one of the following four default forwarding classes or with a user-configured forwarding class to assign an output queue to the packet:
best-effort (be)—Provides no service profile. Loss priority is typically not carried in a CoS value.
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 two drop probabilities: low and high.
network-control (nc)—Supports protocol control and thus is typically high priority.
The switch supports up to eight (QFX10000 and NFX Series devices), 10 (QFX5200 switches), or 12 (other switches) forwarding classes, thus enabling flexible, differentiated, packet classification. For example, you can configure multiple classes of best-effort traffic such as best-effort, best-effort1, and best-effort2.
On QFX10000 and NFX Series devices, unicast and multidestination (multicast, broadcast, and destination lookup fail) traffic use the same forwarding classes and output queues.
Except on QFX10000 and NFX Series devices, a switch supports 8 queues for unicast traffic (queues 0 through 7) and 2 (QFX5200 switches) or 4 (other switches) output queues for multidestination traffic (queues 8 through 11). Forwarding classes mapped to unicast queues are associated with unicast traffic, and forwarding classes mapped to multidestination queues are associated with multidestination traffic. You cannot map unicast and multidestination traffic to the same queue. You cannot map a strict-high priority queue to a multidestination forwarding class because queues 8 through 11 do not support strict-high priority configuration.
Default Forwarding Classes
Table 1 shows the four default forwarding classes that apply to all switches but not NFX Series devices. Except on QFX10000, these forwarding classes apply to unicast traffic. You can rename the forwarding classes. Assigning a new forwarding class name does not alter the default classification or scheduling applied to the queue that is mapped to that forwarding class. CoS configurations can be complex, so unless it is required by your scenario, we recommend that you use the default class names and queue number associations.
Forwarding Class Name |
Default Queue Mapping |
Comments |
|---|---|---|
best-effort |
0 |
The software does not apply any special CoS handling to best-effort traffic. This is a backward compatibility feature. Best-effort traffic is usually the first traffic to be dropped during periods of network congestion. By default, this is a lossy forwarding class with a packet drop
attribute of |
fcoe |
3 |
By default, the Note:
By convention, deployments with converged server access typically
use IEEE 802.1p priority 3 (011) for FCoE traffic. The default mapping
of the We recommend that you use priority 3 for FCoE traffic unless your network architecture requires that you use a different priority. |
no-loss |
4 |
By default, this is a lossless forwarding class with a packet
drop attribute of |
network-control |
7 |
The software delivers packets in this service class with a high 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, packet delay is preferable to packet discard. By default, this is a lossy forwarding class with a packet drop
attribute of |
Table 2 applies only to multidestination traffic except on QFX10000 switches and NFX Series devices.
Forwarding Class Name |
Default Queue Mapping |
Comments |
|---|---|---|
mcast |
8 |
The software does not apply any special CoS handling to the multidestination packets. These packets are usually dropped under congested network conditions. By default, this is a lossy forwarding class with a packet drop
attribute of |
Mirrored traffic is always sent to the queue that corresponds to the multidestination forwarding class. The switched copy of the mirrored traffic is forwarded with the priority determined by the behavior aggregate classification process.
Forwarding Class Configuration Rules
Take the following rules into account when you configure forwarding classes:
Queue Assignment Rules
The following rules govern queue assignment:
CoS configurations that specify more queues than the switch can support are not accepted. The commit operation fails with a detailed message that states the total number of queues available.
All default CoS configurations are based on queue number. The name of the forwarding class that appears in the default configuration is the forwarding class currently mapped to that queue.
(Except QFX10000 and NFX Series devices) Only unicast forwarding classes can be mapped to unicast queues (0 through 7), and only multidestination forwarding classes can be mapped to multidestination queues (8 through 11).
(Except QFX10000 and NFX Series devices) Strict-high priority queues cannot be mapped to multidestination forwarding classes. (Strict-high priority traffic cannot be mapped to queues 8 through 11).
If you map more than one forwarding class to a queue, all of the forwarding classes mapped to the same queue must have the same packet drop attribute: either all of the forwarding classes must be lossy or all of the forwarding classes must be lossless.
You can limit the amount of traffic that receives strict-high priority treatment on a strict-high priority queue by configuring a transmit rate. The transmit rate sets the amount of traffic on the queue that receives strict-high priority treatment. The switch treats traffic that exceeds the transmit rate as low priority traffic that receives the queue excess rate bandwidth. Limiting the amount of traffic that receives strict-high priority treatment prevents other queues from being starved while also ensuring that the amount of traffic specified in the transmit rate receives strict-high priority treatment.
Except on QFX10000 and NFX Series devices, you can use the shaping-rate statement to throttle the rate of packet transmission by setting a maximum bandwidth. On QFX10000 and NFX Series devices, you can use the transmit rate to set a limit on the amount of bandwidth that receives strict-high priority treatment on a strict-high priority queue.
On QFX10000 and NFX Series devices, if you configure more than one strict-high priority queue on a port, you must configure a transmit rate on each of the strict-high priority queues. If you configure more than one strict-high priority queue on a port and you do not configure a transmit rate on the strict-high priority queues, the switch treats only the first queue you configure as a strict-high priority queue. The switch treats the other queues as low priority queues. If you configure a transmit rate on some strict-high priority queues but not on other strict-high priority queues on a port, the switch treats the queues that have a transmit rate as strict-high priority queues, and treats the queues that do not have a transmit rate as low priority queues.
Scheduling Rules
When you configure a forwarding class and map traffic to it (that is, you are not using a default classifier and forwarding class), you must also define a scheduling policy for the forwarding class.
Defining a scheduling policy means:
Mapping a scheduler to the forwarding class in a scheduler map
Including the forwarding class in a forwarding class set
Associating the scheduler map with a traffic control profile
Attaching the traffic control profile to a forwarding class set and applying the traffic control profile to an interface
On QFX10000 switches and NFX Series devices, you can define a scheduling policy using port scheduling as follows:
Mapping a scheduler to the forwarding class in a scheduler map
Applying the scheduler map to one or more interfaces
Rewrite Rules
On each physical interface, either all forwarding classes that are being used on the interface must have rewrite rules configured, or no forwarding classes that are being used on the interface can have rewrite rules configured. On any physical port, do not mix forwarding classes with rewrite rules and forwarding classes without rewrite rules.
Lossless Transport Support
The switch supports up to six lossless forwarding classes. For lossless transport, you must enable PFC on the IEEE 802.1p code point of lossless forwarding classes. The following limitations apply to support lossless transport:
The external cable length from the switch or QFabric system Node device to other devices cannot exceed 300 meters.
The internal cable length from the QFabric system Node device to the QFabric system Interconnect device cannot exceed 150 meters.
For FCoE traffic, the interface maximum transmission unit (MTU) must be at least 2180 bytes to accommodate the packet payload, headers, and checks.
Changing any portion of a PFC configuration on a port blocks the entire port until the change is completed. After a PFC change is completed, the port is unblocked and traffic resumes. Changing the PFC configuration means any change to a congestion notification profile that is configured on a port (enabling or disabling PFC on a code point, changing the MRU or cable-length value, or specifying an output flow control queue). Blocking the port stops ingress and egress traffic, and causes packet loss on all queues on the port until the port is unblocked.
QFX10002-60C does not support PFC and lossless queues; that is, default lossless queues (fcoe and no-loss) will be lossy queues.
Junos OS Release 12.2 introduces changes to the way lossless
forwarding classes (the fcoe and no-loss forwarding
classes) are handled.
In Junos OS Release 12.1, both explicitly configuring the fcoe and no-loss forwarding classes, and using the
default configuration for these forwarding classes, resulted in the
same lossless behavior for traffic mapped to those forwarding classes.
However, in Junos OS Release 12.2, if you explicitly configure
the fcoe or the no-loss forwarding class, that
forwarding class is no longer treated as a lossless forwarding class.
Traffic mapped to these forwarding classes is treated as lossy (best-effort) traffic. This is true even if the explicit configuration
is exactly the same as the default configuration.
If your CoS configuration from Junos OS Release 12.1 or earlier
includes the explicit configuration of the fcoe or the no-loss forwarding class, then when you upgrade to Junos OS
Release 12.2, those forwarding classes are not lossless. To preserve
the lossless treatment of these forwarding classes, delete the explicit fcoe and no-loss forwarding class configuration
before you upgrade to Junos OS Release 12.2.
See Overview of CoS Changes Introduced in Junos OS Release 12.2 for detailed information about this change and how to delete an existing lossless configuration.
In Junos OS Release 12.3, the default behavior of the fcoe and no-loss forwarding classes is the same as in Junos
OS Release 12.2. However, in Junos OS Release 12.3, you can configure
up to six lossless forwarding classes. All explicitly configured lossless
forwarding classes must include the new no-loss packet
drop attribute or the forwarding class is lossy.