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 class of service (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 device 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 3000 Series device, a system class is uniquely identified by a qos-group value. A total of eight system classes are supported. The Cisco Nexus 3000 Series switch supports one default class which is always present on the switch. Up to seven additional system classes can be created by the administrator.

The device 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.

The device 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.

      Note	Cisco Nexus 3000 Series supports one MTU for all classes for all ports.

    • Set CoS value—This configuration is used to mark 802.1p values for all traffic mapped to this system class.
    • Congestion Control WRED—Weighted random early detection (WRED) anticipates and avoids congestion before congestion occurs. WRED drops packets, based on the average queue length that exceeds a specific threshold value, to indicate congestion. You can configure congestion avoidance with WRED in egress policy maps. By default, tail-drop is the congestion control mechanism. To enable WRED, use the congestion-control random-detect command in network-qos policy map mode.
    • ECN—ECN is an extension to WRED that marks packets instead of dropping them when the average queue length exceeds a specific threshold value. When configured with the WRED explicit congestion notification (ECN) feature, routers and end hosts use this marking as a signal that the network is congested to slow down sending packets. To enable an ECN, use the congestion-control random-detect ecn command in the network-qos policy map mode.

      Note	Enabling WRED and ECN on a class on a network-qos policy implies that WRED and ECN is enabled for all ports in the system.

• Type queuing—A type queuing policy is used to define the scheduling characteristics of the queues associated with system classes. Cisco Nexus 3000 Series supports type queuing in the egress direction.

  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 queuing policy is used to configure output queues on the device associated with system classes.

    • 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.
  • 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 that corresponds to the system class this traffic flow is mapped to.
      • Cisco Nexus 3000 Series supports the following:
        • Eight QoS groups
        • Eight queues for unicast
        • Four queues for multicast
        By default, two QoS groups each are mapped to one multicast queue. The mapping is QoS group 0 and 1 are mapped to a multicast queue, QoS group 2 and 3 are mapped to the next and so forth.

The Cisco Nexus 3000 Series supports one MTU for all classes for all ports.

When configuring MTU, follow these guidelines:

• For the Cisco Nexus 3000 Series device, the MTU is controlled by the value configured on the class default. The same MTU must be configured on all classes.
• 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 1500 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 default system class has a default MTU of 1500 bytes. You can configure this value.
• You can specify the MTU value for either a single Layer 3 interface or a range of Layer 3 interfaces. When you change the Layer 3 interface MTU value to the jumbo MTU value (1500 bytes or greater), you must also change the network QoS MTU value to 1500 bytes or greater. The device generates a syslog message to inform you of this requirement.

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

• 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.
• You can override the default untagged CoS value for an Ethernet interface or a port channel interface using the untagged cos cos-value command.
• You can override the default untagged Cos value for an Ethernet or a Layer 3 interface or a port channel interface using the untagged cos cos-value command.

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 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 or you can determine the 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.

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.
• 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 device 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 bridge protocol data units (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.

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:

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 for ingress traffic only.

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 for input or output traffic.

You can configure an explicit congestion notification (ECN) threshold per class in a queuing policy and apply it to an interface.

Prior to release 5.0(3)U4(1), WRED and an ECN can only be enabled or disabled on QoS class in the network-qos policy (with static thresholds). Starting with release 5.0(3)U4(1), an enhanced ECN marking is supported as follows:

• WRED and ECN thresholds can be configured corresponding to a class from the queueing policy by using the following Steps 1 through 8.

  Note	A WRED and ECN still need to be enabled by the network-qos policy class configuration mode.

• Support for enabling WRED and ECN on a global basis outside the MQC command line. You can configure WRED and an ECN at a global buffer level where you enable WRED and an ECN and specify a threshold at the system level by using the following Steps 1 through 9. If this threshold is exceeded, WRED and ECN are applied on all WRED/ECN enabled classes in the system.
• By default, when WRED and an ECN are enabled, the marking or drop happens based on the class or queue threshold. However, when the global based WRED and ECN is also enabled, by using the congestion-control random-detect global-buffer and wred-queue qos-group-map queue-only commands, the WRED and ECN marking behavior initiates when either of the class thresholds or global threshold is exceeded.