Information About Quality of Service
The configurable Cisco NX-OS quality of service (QoS) features allow you to classify the network traffic, prioritize the traffic flow, and provide congestion avoidance.
The default QoS configuration on the device provides best-effort service for Ethernet traffic. QoS can be configured to provide additional classes of service for Ethernet traffic. Cisco NX-OS QoS features are configured using Cisco Modular QoS CLI (MQC).
In the event of congestion or collisions, Ethernet will drop packets. The higher level protocols detect the missing data and retransmit the dropped packets.
Modular QoS CLI
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:
- Define traffic classes.
- Associate policies and actions with each traffic class.
- 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 at egress and for configuring buffer threshold and priority group mapping at ingress.
![]() 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.
System Classes
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.
If service policies are configured at the interface level, the interface-level policy always takes precedence over system class configuration or defaults.
Default System Classes
The device provides the 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.
Information About Policy Types
The device supports a number of policy types. You create class maps in the policy types.
There are three policy types:
-
Network-qos
-
Queuing
-
QoS
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 is 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
The Cisco Nexus device supports one MTU for traffic for all classes for all ports. However, you can have different MTUs for different classes. The MTUs are used for PFC buffer calculation.
-
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.
ECN is supported on all types of Cisco Nexus 3000 series switches.
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.
-
No drop—No drop specifies lossless service for the system class.
-
-
-
Type queuing—The Cisco Nexus device supports type queuing in the ingress and egress directions. Egress type queuing policies are used to define the scheduling characteristics of the queues. Ingress type queuing policies are used to define the pause buffer thresholds, priority group, and queue limit.
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 is 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.
-
Egress queuing policy—The egress queuing policy is used to configure egress queues on the device.
-
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. For Cisco Nexus 3132 and 3172 switches, there are three strict priority levels.
-
Shape and minimum guarantee—Specifies the burst size and minimum guaranteed bandwidth for this queue.
-
Queue limit—Specifies either the static or dynamic queue limit for Cisco Nexus 3100 Series switches. The static queue limit defines the fixed size to which the queue can grow.
-
-
Ingress queuing policy—The ingress queuing policy is used to define the pause buffer thresholds, priority group, and queue limit.
-
Pause buffer threshold—Sets the pause and resume buffer threshold settings for ingress traffic.
-
Priority group—Classifies the traffic and monitors statistics on no-drop classes.
-
Queue limit—Sets the shared buffer usage per priority group.
-
-
You can configure the threshold for using shared buffers both at ingress and egress based on the alpha value, which is derived from the index. The index ranges from 0 to 9 for Cisco Nexus 3000 series switches and from 0 to 10 for Cisco Nexus 3100 platform switches. At ingress, the alpha value is used to calculate the per port, per priority group share of the buffers available from the current free pool. At egress, the alpha value is used to calculate the per port, per queue share of the buffers available from the current free pool.
For the Cisco Nexus 3000 series switches, the alpha values are as follows:
Index Alpha Value 0 1/64 1 1/32 2 1/16 3 1/8 4 1/4 5 1/2 6 1 7 2 8 4 9
Note Index 9 is not applicable for Cisco Nexus 34180YC.
Cisco Nexus 34180YC has an index range from 0 to 8.
8
For the Cisco Nexus 3100 platform switches, the alpha values are as follows:
Index Alpha Value 0 1/128 1 1/64 2 1/32 3 1/16 4 1/8 5 1/4 6 1/2 7 1 8 2 9
Note Index 9 is not applicable for Cisco Nexus 34180YC.
Cisco Nexus 34180YC has an index range from 0 to 8.
4 10
Note Index 10 is not applicable for Cisco Nexus 34180YC.
Cisco Nexus 34180YC has an index range from 0 to 8.
8 -
-
To determine the default shared alpha value, use one of the following commands:
-
For Cisco NX-OS 6.x, use the test hardware internal bcm-usd bcm-diag-shell command to determine the default shared alpha value.
For example:
switch# test hardware internal bcm-usd bcm-diag-shell Available Unit Numbers: 0 bcm-shell.0> d chg MMU_THDU_XPIPE_CONFIG_QUEUE MMU_THDU_XPIPE_CONFIG_QUEUE.mmu0[0]: <Q_SHARED_LIMIT_CELL=7,Q_SHARED_ALPHA_CELL=7,Q_MIN_LIMIT_CELL=0xb, Q_LIMIT_DYNAMIC_CELL=1,Q_COLOR_LIMIT_DYNAMIC_CELL=1,DATA=0x000000000c00160007>
-
For Cisco NX-OS 7.x, use the bcm-shell module 1 command to determine the default shared alpha value.
For example:
switch# bcm-shell module 1 Available Unit Numbers: 0 bcm-shell.0> d chg MMU_THDU_XPIPE_CONFIG_QUEUE MMU_THDU_XPIPE_CONFIG_QUEUE.mmu0[0]: <Q_SHARED_LIMIT_CELL=7,Q_SHARED_ALPHA_CELL=7,Q_MIN_LIMIT_CELL=0xb, Q_LIMIT_DYNAMIC_CELL=1,Q_COLOR_LIMIT_DYNAMIC_CELL=1,DATA=0x000000000c00160007>
-
-
In dynamic mode, the amount of shared buffer a port can consume based on the alpha parameter is the queue's threshold: alpha value * (number of unused cells in the buffer). In general, as the number of unused cells decreases (ie. the buffer becomes fuller), the queue's threshold reduces.
-
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.
The Cisco Nexus 3000 Series switches support:
-
Eight QoS groups
-
Eight queues for unicast
-
Four queues for multicast
Note Cisco Nexus 34180YC has eight queues for both unicast and multicast.
The Cisco Nexus 3100 platform switches support:
-
Eight QoS groups
-
Eight queues for unicast
-
Eight queues for multicast
For Cisco Nexus 3100 platform switches, each QoS group is mapped to one multicast queue. The mapping is QoS group 0 mapped to multicast queue 1, QoS group 1 mapped to multicast queue 2, and so forth.
-
-
-
MTU
The Cisco Nexus device supports one MTU for all classes for all ports.
When configuring MTU, follow these guidelines:
-
For the Cisco Nexus device, the MTU is controlled by the value configured on the class default.
-
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.
- You can set the MTU per class of the network-qos policy. The MTU that is set is used to decide the buffer allocations for PFC. On a need basis, you can configure some classes to have an MTU of 9216 and some to have an MTU of 1500, depending on the type of traffic expected on that class. This will help the system configure the PFC buffers when a class is configured as a no-drop-class.
-
On Cisco Nexus 3500 Switches, MTU for all classes must be same as the one configured for the default-class.
Trust Boundaries
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.
Note
For Cisco Nexus 34180YC, all ports are trusted interfaces.
-
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.
Ingress Classification Policies
You use classification to partition traffic into classes. You classify the traffic based on the packet property (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.
Traffic that fails to match any class is assigned to a default class of traffic called class-default.
Priority Groups for No-Drop Classes
In Cisco Nexus 3000 series switches and Cisco Nexus 3100 platform switches, packets are handled as cells. Each cell holds 208 bytes of data. One packet can be split into many cells, but each cell can contain a maximum of one packet. Priority groups are groups of cells on which the PFC thresholds are applied. They apply only to no-drop classes and are used for classifying traffic and monitoring statistics.
![]() Note |
For Cisco Nexus 34180YC, the maximum amount of data in a cell is 80 bytes. |
You can associate a no-drop class with a priority group number in the input queuing policy map to guarantee MTU buffers for the specified traffic class. The pause thresholds for the no-drop class are applied on the priority group.
By default, the priority group number is assigned by the system. You can override it by using the priority-group command.
![]() Note |
You cannot have multiple no-drop classes mapped to the same priority group. |
Egress Queuing Policies
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.
Each Ethernet interface supports up to eight queues, one for each system class. The queues have the following default configuration:
-
In addition to these queues, control traffic that is destined for the CPU uses strict priority queues. These queues are not accessible for user configuration.
Note
For Cisco Nexus 34180YC, queue 7 is used for CPU traffic and is user configurable. However, as a best practice do not change queue 7 from strict priority to any other type of scheduling. Congesting queue 7 with data traffic leads to control packet loss.
-
Standard Ethernet traffic in the default drop system class is assigned a queue. This queue uses WRR scheduling with 100 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 one strict priority queue for Cisco Nexus 3000 series switches and Cisco Nexus 3500 platform switches. This queue is serviced before all other queues except the control traffic queue (which carries control rather than data traffic).
![]() Note |
Cisco Nexus 34180YC supports a maximum of seven priority queues. |
You can configure up to three strict priority queues with multiple priority levels on Cisco Nexus 3100 platform switches.
![]() Note |
Cisco Nexus 34180YC supports a maximum of seven priority queues. |
QoS for Traffic Directed to the CPU
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.