The Cisco Modular QoS CLI (MQC) provides a standard set of commands for configuring QoS.

You can use MQC to define additional traffic classes and to configure QoS policies for the whole system and for individual interfaces. Configuring a QoS policy with MQC consists of the following steps:

1. Define traffic classes.
2. Associate policies and actions with each traffic class.
3. Attach policies to logical or physical interfaces as well as at the global system level.

MQC provides two command types to define traffic classes and policies:

• class-map—Defines a class map that represents a class of traffic based on packet-matching criteria. Class maps are referenced in policy maps.

  The class map classifies incoming packets based on matching criteria, such as the IEEE 802.1p CoS value. Unicast and multicast packets are classified.

• policy-map—Defines a policy map that represents a set of policies to be applied on a class-by-class basis to class maps.

  The policy map defines a set of actions to take on the associated traffic class, such as limiting the bandwidth or dropping packets.

You define the following class-map and policy-map object types when you create them:

• network-qos—Defines MQC objects that you can use for system level related actions.

• qos—Defines MQC objects that you can use for classification.

• queuing—Defines MQC objects that you can use for queuing and scheduling.

Note	The qos type is the default for the class-map and policy-map commands, but not for the service-policy which requires that you specify an explicit type.

You can attach policies to interfaces or EtherChannels as well as at the global system level by using the service-policy command.

You can view all or individual values for MQC objects by using the show class-map and show policy-map commands.

An MQC target is an entity (such as an Ethernet interface) that represents a flow of packets. A service policy associates a policy map with an MQC target, and specifies whether to apply the policy on incoming or outgoing packets. This mapping enables the configuration of QoS policies such as marking, bandwidth allocation, buffer allocation, and so on.

The system qos is a type of MQC target. You use a service-policy to associate a policy map with the system qos target. A system qos policy applies to all interfaces on the switch unless a specific interface has an overriding service-policy configuration. The system qos policies are used to define system classes, the classes of traffic across the entire switch, and their attributes. To ensure QoS consistency (and for ease of configuration), the switch distributes the system class parameter values to all its attached network adapters using the Data Center Bridging Exchange (DCBX) protocol.

If service policies are configured at the interface level, the interface-level policy always takes precedence over system class configuration or defaults.

On the Cisco Nexus 5000 Series switch, a system class is uniquely identified by a qos-group value. A total of six system classes are supported. Two of the six system classes are defaults and are always present on the switch. Up to four additional system classes can be created by the administrator.

The Cisco Nexus 5000 Series switch provides the following system classes:

• Drop system class

  By default, the software classifies all unicast and multicast Ethernet traffic into the default drop system class. This class is identified by qos-group 0.

  This class is created automatically when the system starts up (the class is named class-default in the CLI). You cannot delete this class and you cannot change the match criteria associated with the default class.

• FCoE system class (For the Cisco Nexus 5010 switch and the Cisco Nexus 5020 switch)

  All Fibre Channel and FCoE control and data traffic is automatically classified into the FCoE system class, which provides no-drop service.

  This class is created automatically when the system starts up (the class is named class-fcoe in the CLI).

  You cannot delete class-fcoe and you can only modify the IEEE 802.1p CoS value to associate with this class. This class is identified by qos-group 1.

  The switch classifies packets into the FCoE system class as follows:

  • FCoE traffic is classified based on EtherType.

  • Native Fibre Channel traffic is classified based on the physical interface type.

    Note	The optional N5K-M1404 or N5K-M1008 expansion modules provide native ½/4-Gigabit Fibre Channel ports.

• FCoE system class (For the Cisco Nexus 5548 switch)

  For the Cisco Nexus 5548 switch, the class-fcoe is not automatically created. Before you enable FCoE on the Cisco Nexus 5548 switch running Cisco NX-OS Release 5.0(2)N1(1), you must enable class-fcoe in the three types of qos policies:

  • type qos policy maps

  • type network-qos policy map (attached to system qos)

  • type queuing policy map (class-fcoe must be configured with a non-zero bandwidth percentage for input queuing policy maps.

    When class-fcoe is not included in the qos policies, vFC interfaces do not come up and increased drops occur.

  Note	The Cisco Nexus 5548 switch supports five user-defined classes and one default drop system class.

The Cisco Nexus 5000 Series switch supports a number of policy types. You create class maps in the policy types.

There are three policy types. The following QoS parameters can be specified for each type of class:

• Type network-qos—A network-qos policy is used to instantiate system classes and associate parameters with those classes that are of system-wide scope.

  • Classification—The traffic that matches this class are as follows:

    • QoS Group—A class-map of type network-qos identifies a system-class and is matched by its associated qos-group.

  • Policy—The actions that are performed on the matching traffic are as follows:

    Note	A network-qos policy can only be attached to the system qos target.

    • MTU—The MTU that needs to be enforced for the traffic that is mapped to a system class. Each system class has a default MTU and the system class MTU is configurable.

    • Multicast optimization—This configuration specifies if the performance of multicast traffic mapped to this class will be optimized.

    • Pause no-drop—No drop specifies lossless service for the system class. Drop specifies that tail drop is used (arriving packets are dropped when the queue reaches its allocated size) when a queue for this system class is full.

      An additional parameter pfc-cos can be configured. This parameter identifies the class of service (CoS) values to assert priority flow control (PFC) when traffic for a no-drop system class is not mapped based purely on CoS experiences congestion.

    • Queue Limit—This configuration specifies the number of buffers that need to be reserved to the queues of this system class. This option is not configurable for no-drop system classes.

    • Set CoS value—This configuration is used to mark 802.1p values for all traffic mapped to this system class. For the Cisco Nexus 5020 switch and the Cisco Nexus 5010 switch, the marking value for a system class needs to be unique and cannot be used as a marking value for any other system class. The marking value does not need to be unique for the Cisco Nexus 5548 switch.

• Type queuing—A type queuing policy is used to define the scheduling characteristics of the queues associated with system classes.

  Note	Some configuration parameters when applied to an EtherChannel are not reflected on the configuration of the member ports.

  • Classification—The traffic that matches this class are as follows:

    • QoS Group—A class-map of type queuing identifies a system-class and is matched by its associated qos-group.

  • Policy—The actions that are performed on the matching traffic are as follows:

    Note

    These policies can be attached to the system qos target or to any interface. The output queueing policy is used to configure output queues on the switch associated with system classes. The input queuing policy is used to configure scheduling for queues in the CNA. The input queuing policy parameters are signalled to the CNA over the DCBX protocol.

    • Bandwidth—Sets the guaranteed scheduling deficit weighted round robin (DWRR) percentage for the system class.

    • Priority—Sets a system class for strict-priority scheduling. Only one system class can be configured for priority in a given queuing policy.

• Type qos—A type qos policy is used to classify traffic that is based on various Layer 2, Layer 3, and Layer 4 fields in the frame and to map it to system classes.

  Note	Some configuration parameters when applied to an EtherChannel are not reflected on the configuration of the member ports.

  • Classification—The traffic that matches this class are as follows:

    • Access Control Lists—Classifies traffic based on the criteria in existing ACLs.

    • Class of Service—Matches traffic based on the CoS field in the frame header.

    • DSCP—Classifies traffic based on the Differentiated Services Code Point (DSCP) value in the DiffServ field of the IP header.

    • IP Real Time Protocol—Classifies traffic on the port numbers used by real-time applications.

    • Precedence—Classifies traffic based on the precedence value in the type of service (ToS) field of the IP header.

    • Protocol—Classifies traffic based on the protocol field of the IP header.

  • Policy—The actions that are performed on the matching traffic are as follows:

    Note	This policy can be attached to the system or to any interface. It applies to input traffic only.

    • QoS Group—Sets the qos-group corresponding to the system class this traffic flow is mapped to.

IEEE 802.3x link-level flow control allows a congested receiver to communicate a transmitter at the other end of the link to pause its data transmission for a short period of time. The link-level flow control feature applies to all the traffic on the link.

The transmit and receive directions are separately configurable. By default, link-level flow control is disabled for both directions.

On the Cisco Nexus 5000 Series switch, Ethernet interfaces do not automatically detect the link-level flow control capability. You must configure the capability explicitly on the Ethernet interfaces.

On each Ethernet interface, the switch can enable either priority flow control or link-level flow control (but not both).

Priority flow control (PFC) allows you to apply pause functionality to specific classes of traffic on a link instead of all the traffic on the link. PFC applies pause functionality based on the IEEE 802.1p CoS value. When the switch enables PFC, it communicates to the adapter which CoS values to apply the pause.

Ethernet interfaces use PFC to provide lossless service to no-drop system classes. PFC implements pause frames on a per-class basis and uses the IEEE 802.1p CoS value to identify the classes that require lossless service.

In the switch, each system class has an associated IEEE 802.1p CoS value that is assigned by default or configured on the system class. If you enable PFC, the switch sends the no-drop CoS values to the adapter, which then applies PFC to these CoS values.

The default CoS value for the FCoE system class is 3. This value is configurable.

By default, the switch negotiates to enable the PFC capability. If the negotiation succeeds, PFC is enabled and link-level flow control remains disabled regardless of its configuration settings. If the PFC negotiation fails, you can either force PFC to be enabled on the interface or you can enable IEEE 802.x link-level flow control.

If you do not enable PFC on an interface, you can enable IEEE 802.3X link-level pause. By default, link-level pause is disabled.

The Cisco Nexus 5000 Series switch is a Layer 2 switch, and it does not support packet fragmentation. A maximum transmission unit (MTU) configuration mismatch between ingress and egress interfaces may result in packets being truncated.

When configuring MTU, follow these guidelines:

• MTU is specified per system class. The system class allows a different MTU for each class of traffic but they must be consistent on all ports across the entire switch. You cannot configure MTU on the interfaces.

• Fibre Channel and FCoE payload MTU is 2158 bytes across the switch. As a result, the rxbufsize for Fibre Channel interfaces is fixed at 158 bytes. If the Cisco Nexus 5000 Series switch receives an rxbufsize from a peer that is different than 2158 bytes, it will fail the exchange of link parameters (ELP) negotiation and not bring the link up.

• Enter the system jumbomtu command to define the upper bound of any MTU in the system. The system jumbo MTU has a default value of 9216 bytes. The minimum MTU is 21 58 bytes and the maximum MTU is 9216 bytes.

• The system class MTU sets the MTU for all packets in the class. The system class MTU cannot be configured larger than the global jumbo MTU.

• The FCoE system class (for Fibre Channel and FCoE traffic) has a default MTU of 2158 bytes. This value cannot be modified.

• The default drop system class has a default MTU of 1500 bytes. You can configure this value.

• The switch sends the MTU configuration to network adapters that support DCBX.

  Note	MTU is not supported in Converged Enhanced Ethernet (CEE) mode for DCBX.

The trust boundary is enforced by the incoming interface as follows:

• All Fibre Channel and virtual Fibre Channel interfaces are automatically classified into the FCoE system class.

• By default, all Ethernet interfaces are trusted interfaces.The 802.1p CoS and DSCP are preserved unless the marking is configured. There is no default CoS to queue and DSCP to queue mapping. You can define and apply a policy to create these mappings. By default, without a user defined policy, all traffic is assigned to the default queue.

• Any packet that is not tagged with an 802.1p CoS value is classified into the default drop system class. If the untagged packet is sent over a trunk, it is tagged with the default untagged CoS value, which is zero.

• You can override the default untagged CoS value for an Ethernet interface or port channel.

After the system applies the untagged CoS value, QoS functions the same as for a packet that entered the system tagged with the CoS value.

You can associate an ingress policy map with an Ethernet interface to guarantee bandwidth for the specified traffic class or to specify a priority queue.

The ingress policy is applied in the adapter to all outgoing traffic that matches the specified CoS value.

When you configure an ingress policy for an interface, the switch sends the configuration data to the adapter. If the adapter does not support the DCBX protocol or the ingress policy type-length-value (TLV), the ingress policy configuration is ignored.

You use classification to partition traffic into classes. You classify the traffic based on the port characteristics (CoS field) or the packet header fields that include IP precedence, Differentiated Services Code Point (DSCP), and Layer 2 to Layer 4 parameters. The values used to classify traffic are called match criteria. When you define a traffic class, you can specify multiple match criteria, you can choose to not match on a particular criterion, or you can determine traffic class by matching any or all criteria.

Traffic that fails to match any class is assigned to a default class of traffic called class-default.

You can associate an egress policy map with an Ethernet interface to guarantee the bandwidth for the specified traffic class or to configure the egress queues.

The bandwidth allocation limit applies to all traffic on the interface including any FCoE traffic.

Each Ethernet interface supports up to six queues, one for each system class. The queues have the following default configuration:

• In addition to the six queues, control traffic that is destined for the CPU uses strict priority queues. These queues are not accessible for user configuration.

• FCoE traffic (traffic that maps to the FCoE system class) is assigned a queue. This queue uses weighted round-robin (WRR) scheduling with 50 percent of the bandwidth.

• Standard Ethernet traffic in the default drop system class is assigned a queue. This queue uses WRR scheduling with 50 percent of the bandwidth.

If you add a system class, a queue is assigned to the class. You must reconfigure the bandwidth allocation on all affected interfaces. Bandwidth is not dedicated automatically to user-defined system classes.

You can configure a strict priority queue. This queue is serviced before all other queues except the control traffic queue (which carries control rather than data traffic).

The six multicast queues applies to Nexus 5010 and Nexus 5020. For Nexus 5548 there are 128 multicast queues. Additionally we need to highlight these are the queues at ingress.

For the Cisco Nexus 5548 switch, Cisco NX-OS Release 5.0(2)N1(1) provides 128 multicast queues at ingress. For the Cisco Nexus 5020 switch and the Cisco Nexus 5020 switch, the system provides six multicast queues per interface and allocates one queue for each system class. By default, all multicast Ethernet traffic is classified into the default drop system class. This traffic is serviced by one multicast queue.

Optimized multicasting allows use of the unused multicast queues to achieve better throughput for multicast frames. If optimized multicast is enabled for the default drop system class, the system will use all six queues to service the multicast traffic (all six queues are given equal priority).

If you define a new system class, a dedicated multicast queue is assigned for this class. This queue is removed from the set of queues available for the optimized multicast class.

Optimized multicasting achieves better throughput and improves performance for multicast frames.

The system provides two predefined class maps for matching broadcast or multicast traffic. These class maps are convenient for creating separate policy maps for unicast and multicast traffic. The predefined class maps are as follows:

• class-all-flood

  The class-all-flood class map matches all broadcast, multicast, and unknown unicast traffic (across all CoS values). If you configure a policy map with the class-all-flood class map, the system automatically uses all available multicast queues for this traffic.

• class-ip-multicast

  The class-ip-multicast class map matches all IP multicast traffic. Policy options configured in this class map apply to traffic across all Ethernet CoS values. For example, if you enable optimized multicast for this class, the IP multicast traffic for all CoS values is optimized.

Note	If you configure either of these predefined class maps as a no-drop class, the priority flow control capability is applied across all Ethernet CoS values. In this configuration, pause will be applied to unicast and multicast traffic.

The egress queues are not configurable for native Fibre Channel interfaces. Two queues are available as follows:

• A strict priority queue to serve high-priority control traffic.

• A queue to serve all data traffic and low-priority control traffic.

The switch automatically applies QoS policies to traffic that is directed to the CPU to ensure that the CPU is not flooded with packets. Control traffic, such as BPDU frames, is given higher priority to ensure delivery.

You can classify traffic by matching packets based on an existing access control list (ACL). Traffic is classified by the criteria defined in the ACL. The permit and deny ACL keywords are ignored in the matching; even if a match criteria in the access-list has a deny action, it is still used for matching for this class.

You can classify traffic based on the class of service (CoS) in the IEEE 802.1Q header. This 3-bit field is defined in IEEE 802.1p to support QoS traffic classes. CoS is encoded in the high order 3 bits of the VLAN ID Tag field and is referred to as user_priority.

If a system class is configured with a no-drop function, the match cos command serves an additional purpose. The switch sends the CoS value to the adapter so that the adapter will apply a PFC pause for this CoS value.

The FCoE system class has a default CoS value of 3. You can add a match cos configuration to the FCoE system class to set a different CoS value. A PFC pause will be applied to traffic that matches the new value.

You can classify traffic based on the Differentiated Services Code Point (DSCP) value in the DiffServ field of the IP header (either IPv4 or IPv6). The following table shows the standard DSCP values:

The IP Real-time Transport Protocol (RTP) is a transport protocol for real-time applications that transmits data such as audio or video and is defined by RFC 3550. Although RTP does not use a common TCP or UDP port, you typically configure RTP to use ports 16384 to 32767. UDP communications use an even port and the next higher odd port is used for RTP Control Protocol (RTCP) communications.

You can classify based on UDP port ranges, which are likely to target applications using RTP.

You can classify traffic based on the precedence value in the type of service (ToS) byte field of the IP header (either IPv4 or IPv6). The following table shows the precedence values:

You can classify traffic based on the protocol field in the IP header. The following table shows the protocol arguments:

You can classify traffic based on the value of the QoS group internal label, that represents a system class. You can set the value of the QoS group within a policy map using the set qos-group command.

Type qos policies are used for classifying the traffic of a specific system class identified by a unique qos-group value. A type qos policy can be attached to the system or to individual interfaces (including Fabric Extender host interfaces) for ingress traffic only.

Beginning with Cisco Release NX-OS Release 5.0(2)N1(1), for the Cisco Nexus 5548 switch, you can set a maximum of five qos groups for ingress traffic.

Type network qos policies can only be configured on the system qos attachment point. They are applied to the entire switch for a particular class.

Type queuing policies are used for scheduling and buffering the traffic of a specific system class. A type queuing policy is identified by its qos-group and can be attached to the system or to individual interfaces (except for Fabric Extender host interfaces) for input or output traffic.

By default, Ethernet interfaces negotiate PFC with the network adapter using the DCBX protocol. When PFC is enabled, PFC is applied to traffic that matches the CoS value configured for the no-drop class.

You can override the negotiation result by forcing the interface to enable PFC.

By default, LLC on Ethernet interfaces is disabled. You can enable LLC for the transmit and receive directions.