Understanding CoS Fabric Forwarding Class Sets

Default Fabric Forwarding Class Sets

Interconnect devices have 12 default fabric fc-sets, including five visible default fabric fc-sets, four for unicast traffic and one for multidestination (multicast, broadcast, and destination lookup failure) traffic.

There are also seven hidden default fabric fc-sets. There are three hidden default fabric fc-sets for multidestination traffic that you can use if you want to map different multidestination forwarding classes to different multidestination fabric fc-sets. There are four hidden default fabric fc-sets for lossless traffic that you can use to map different lossless forwarding classes (priorities) to different lossless fabric fc-sets. Table 1 shows the default fabric fc-sets:

The five default forwarding classes (best-effort, fcoe, no-loss, network-control, and mcast) are mapped to the fabric fc-sets by default as shown in Table 2.

The maximum fiber cable length between the QFabric system Node device and the QFabric system Interconnect device is 150 meters.

If you want to map different multidestination forwarding classes to different multidestination fabric fc-sets, use one or more of the hidden multidestination fabric fc-sets.

When you define new forwarding classes on a Node device, you explicitly map those forwarding classes to Node device fc-sets. However, new (user-created) forwarding classes are mapped by default to fabric fc-sets. (You can override the default mapping if you want to configure the forwarding class to fabric fc-set mapping explicitly, as described in the next section.)

By default:

• All best-effort traffic forwarding classes that you create are mapped to the fabric_fcset_be fabric fc-set.

• All lossless traffic forwarding classes that you create are mapped to the fabric_fcset_noloss1 or fabric_fcset_noloss2 fabric fc-set.

  Note:

  To avoid fate sharing, we recommend that you configure one-to-one mapping of user-configured lossless forwarding classes to lossless fabric fc-sets instead of using the default mapping. You can also use firewall filters to mitigate fate sharing by separating flows that belong to the same forwarding class as the traffic traverses the Interconnect device (see Understanding How to Mitigate Fate Sharing on a QFabric System Interconnect Device by Remapping Traffic Flows (Forwarding Classes) for more information.)

• All multidestination traffic forwarding classes that you create are mapped to the fabric_fcset_multicast1 fabric fc-set.

• All strict-high priority traffic and network-control forwarding classes that you create are mapped to the fabric_fcset_strict_high fabric fc-set.

Fabric Forwarding Class Set Configuration and Implementation

You can map forwarding classes to fabric fc-sets and configure CoS scheduling for fabric fc-sets. This section describes:

• Mapping Forwarding Classes to Fabric Forwarding Class Sets
• Fabric Forwarding Class Set Implementation

QFabric System CoS

When traffic enters and exits the same QFabric system Node device, CoS works the same as it works on a standalone switch.

However, when traffic enters a QFabric system Node device, crosses the Interconnect device, and then exits a different Node device, CoS is applied differently:

1. Traffic entering the ingress Node device receives the CoS configured at the Node ingress (packet classification and congestion notification profile for PFC).

2. When traffic goes from the ingress Node device to the Interconnect device, the fabric fc-set CoS is applied to the traffic.

3. When traffic goes from the Interconnect device to the egress Node device, the egress Node device applies CoS at the egress port (egress queue scheduling, WRED, and IEEE 802.1p or DSCP code-point rewrite).

Traffic that traverses the Interconnect device can use the default CoS fabric scheduling or you can configure two-tier hierarchical CoS scheduling explicitly on fabric fc-sets as described in Understanding CoS Scheduling Across the QFabric System.

Support for Flow Control and Lossless Transport Across the Fabric

The Interconnect device incorporates flow control mechanisms to support lossless transport during periods of congestion on the fabric. To support the priority-based flow control (PFC) feature on the Node devices, the fabric interfaces use LLFC to support lossless transport for up to six IEEE 802.1p priorities when the following two configuration constraints are met:

1. The IEEE 802.1p priority used for the traffic that requires lossless transport is mapped to a lossless forwarding class on the Node devices.

2. The lossless forwarding class must be mapped to a lossless fabric fc-set on the Interconnect device (fabric_fcset_noloss1, fabric_fcset_noloss2, fabric_fcset_noloss3, fabric_fcset_noloss4, fabric_fcset_noloss5, or fabric_fcset_noloss6).

When traffic meets the two configuration constraints, the fabric propagates the back pressure from the egress Node device across the fabric to the ingress Node device during periods of congestion. However, to achieve end-to-end lossless transport across the switch, you must also configure a congestion notification profile to enable PFC on the Node device ingress ports.

For all other combinations of IEEE 802.1p priority to forwarding class mapping and all other combinations of forwarding class to fabric fc-set mapping, the congestion control mechanism is normal packet drop. For example:

• Case 1—If the IEEE 802.1p priority 5 is mapped to the lossless fcoe forwarding class, and the fcoe forwarding class is mapped to the fabric_fcset_noloss1 fabric fc-set, then the congestion control mechanism is PFC.

• Case 2—If the IEEE 802.1p priority 5 is mapped to the lossless fcoe forwarding class, and the fcoe forwarding class is mapped to the fabric_fcset_be fabric fc-set, then the congestion control mechanism is packet drop.

• Case 3—If the IEEE 802.1p priority 5 is mapped to the lossless no-loss forwarding class, and the no-loss forwarding class is mapped to the fabric_fcset_noloss2 fabric fc-set, then the congestion control mechanism is PFC.

• Case 4—If the IEEE 802.1p priority 5 is mapped to the lossless no-loss forwarding class, and the no-loss forwarding class is mapped to the fabric_fcset_be fabric fc-set, then the congestion control mechanism is packet drop.

• Case 5—If the IEEE 802.1p priority 5 is mapped to the best-effort forwarding class, and the best-effort forwarding class is mapped to the fabric_fcset_be fabric fc-set, then the congestion control mechanism is packet drop.

• Case 6—If the IEEE 802.1p priority 5 is mapped to the best-effort forwarding class, and the best-effort forwarding class is mapped to the fabric_fcset_noloss1 fabric fc-set, then the congestion control mechanism is packet drop.

The number of IEEE 802.1p priorities (forwarding classes) the QFabric system can support for lossless transport across the Interconnect device fabric depends on several factors:

• Approximate fiber cable length—The longer the fiber cable that connects Node device fabric (FTE) ports to the Interconnect device fabric ports, the more data the connected ports need to buffer when a pause is asserted. (The longer the fiber cable, the more frames are traversing the cable when a pause is asserted. Each port must be able to store all of the “in transit” frames in the buffer to preserve lossless behavior and avoid dropping frames.)

• MTU size—The larger the maximum frame sizes the buffer must hold, the fewer frames the buffer can hold. The larger the MTU size, the more buffer space each frame consumes.

• Total number of Node device fabric ports connected to the Interconnect device—The higher the number of connected fabric ports, the more headroom buffer space the Node device needs on those fabric ports to support the lossless flows that traverse the Interconnect device. Because more buffer space is used on the Node device fabric ports, less buffer space is available for the Node device access ports, and a lower total number of lossless flows are supported.

The QFabric system supports six lossless priorities (forwarding classes) under most conditions. The priority group headroom that remains after allocating headroom to lossless flows is sufficient to support best-effort and multidestination traffic.

Table 3 shows how many lossless priorities the QFabric system supports under different conditions (fiber cable lengths and MTUs) in cases when the QFabric system supports fewer than six lossless priorities. The number of lossless priorities is the same regardless of how many Node device FTE ports are connected to the Interconnect device. However, the higher the number of FTE ports connected to the Interconnect device, the lower the number of total lossless flows supported. In all cases that are not shown in Table 3, the QFabric system supports six lossless priorities.

Viewing Fabric Forwarding Class Set Information

You can display information about fabric fc-sets using the same CLI command you use to display information about Node device fc-sets:

Table 4 describes the meaning of the show class-of-service forwarding-class-set output fields when you display fabric fc-set information.

Summary of Fabric Forwarding Class Set and Node Device Forwarding Class Set Differences

Table 5 summarizes the differences between fabric fc-sets and fc-sets: