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.
A classifier must associate each packet with one of the following 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—Delivery of multidestination (multicast, broadcast, and destination lookup fail) packets.
Depending on your platform, the switch supports up to 12 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.
Most QFX devices support 8 queues for unicast traffic (queues 0 through 7) and 4 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 QFX devices. 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 |
|
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.
-
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).
-
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.
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 statement 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
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 to other devices cannot exceed 300 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.
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.
You can configure up to six lossless forwarding classes. All explicitly
configured lossless forwarding classes must include the no-loss
packet drop attribute or the forwarding class is lossy.
Platform-Specific Forwarding Class Behavior
Use the following table to review platform-specific behaviors for your platforms.
|
Platform |
Difference |
|---|---|
|
NFX Series |
|
|
QFX5000 Series |
|
|
QFX10000 Series |
|