- QoS CLI Index
- New and Changed Content for QoS CLI Config Guide
- Preface
- Overview
- Using Modular QoS CLI
- Configuring Classification
- Configuring Marking
- Configuring Mutation Mapping
- Configuring Policing
- Configuring Queuing and Scheduling
- Network QoS Policy Configuration
- Configuring Queuing and Scheduling on F1 Modules
- Configuring Priority Control
- Monitoring QoS Statistics
- Limits Appendix
- Additional References Appendix
- Information About Queuing and Scheduling
- Licensing Requirements for Queuing and Scheduling
- Prerequisites for Queuing and Scheduling
- Guidelines and Limitations
- Configuring Queuing and Scheduling
- Verifying the Queuing and Scheduling Configuration
- Configuration Examples for Queuing and Scheduling on F1 Series Modules
- Feature History for Queuing and Scheduling for F1 Series Module
Configuring Queuing and Scheduling on F1 Series Modules
This chapter describes how to configure the QoS queuing and scheduling features on the F1 Series module of the Cisco NX-OS device. This chapter includes the following sections:
- Information About Queuing and Scheduling
- Licensing Requirements for Queuing and Scheduling
- Prerequisites for Queuing and Scheduling
- Guidelines and Limitations
- Configuring Queuing and Scheduling
- Verifying the Queuing and Scheduling Configuration
- Configuration Examples for Queuing and Scheduling on F1 Series Modules
- Feature History for Queuing and Scheduling for F1 Series Module
Information About Queuing and Scheduling
On an F1 Series module, a queuing policy is closely coupled with the network qos policy. For each network qos policy that is activated, its corresponding default queuing policy is automatically selected for the system target. In the ingress direction, either two or four queues (buffer pools) are formed depending on the policy template. In the egress direction, there are four physical queues for all QoS policy templates.
Note
The system queuing policy applied by default can be overridden on a per-port basis. In general, the user-configured queuing policies are per virtual device context (VDC).
Ingress queuing determines the following attributes:
- Queue-limit—Amount of buffers to be allocated for a class of service (CoS).
- Bandwidth—Priority grouping and its bandwidth allocation advertised using the Data Center Bridging Capability Exchange Protocol (DCBXP).
- Set CoS—Untrusted port default CoS (similar to the M1 modules).
Egress queuing determines the following attributes:
- Bandwidth— Dynamic Weighted Round Robin (DWRR) bandwidth for a given queue and the group.
- Priority level— The priority level of the queue.
- Shape— The shaper for the queue.
This section includes the following topics:
Ingress Queuing
You use the ingress queuing to partition the port ingress buffers that are 1.25 MB and an additional 256 KB (a total of 1.5 MB) to absorb the frames in transit after pause has been sent. This buffer is partitioned among the eight CoS values. The number of partitions is fixed for a given network qos template. The incoming CoS values are mapped to each partition. Each buffer partition is considered as an ingress queue.
There is a high threshold and a low threshold at which the pause or resume frames are generated when a threshold is met. This requirement is applicable to the no-drop CoS only. The frames that are in transit are absorbed by a skid buffer after a pause is generated. If the number of frames exceed the skid buffer threshold, the frames are tail dropped. There are three thresholds for drop eligible (DE), non-DE, and Bridge Protocol Data Unit (BPDU) frames for dropping. For the drop CoS, the high and low thresholds are the same.
The default policy ingress queues are created as follows:
Drop queue =70% buffers; no-drop queue = 30% buffers
Nonpriority queue= 90% buffers; priority queue = 10% buffers.
Each network qos policy has a corresponding default ingress queuing policy (template) and is automatically activated for the system. They are default-4q-8e-in-policy, default-4q-7e-in-policy, default-4q-6e-in-policy, and default-4q-4e-in-policy.
The predefined class map names (queue names) for ingress queuing are described in Table 9-1 .
Note ●
The naming conventions of the queue are similar to the M1 modules. Also, the process for referring to queuing class maps and changing cos to queue maps is also similar to M1 modules.
- When a port becomes part of a port channel, the port inherits the policy of the port channel. When the port is moved out of the port channel, the default system queuing policy gets activated on the port.
The default queuing policy maps the priority and non-priority CoS values of the same class into different queues. However, you can configure a different CoS to queue mapping as needed. You can configure the CoS to queue map on the default VDC but the configuration is applicable system wide.
For example, in an 8e template, the network-admin may want to treat CoS 7 as a non-priority CoS and map it to the non-priority queue.
In the ingress class-map, you can modify the match cos value using the match cos command to configure the desired cos to queue mapping.
Note
Modifying the default queuing policy maps is a disruptive operation and it may can cause frame drops.
You can assign a bandwidth percentage to each ingress queue. The CoS values (priority group) of each queue and its bandwidth are relayed to the peer using the DCBXP.
With the Enhanced Transmission Selection (ETS; specifies scheduling of queues based on priority) implementation, when you define both the drop and no-drop classes in a non-8e network qos policy template, the queuing follows a hierarchical pattern. In a hierarchical queuing pattern, queues within a class are configured with respect to the buffer at the first level, and buffers across the queuing groups are configured at the second level.
You use the queue-limit command to tune the ingress queue sizes (buffers). You can define the percentage of the total buffer to be allocated to the queue. For more information about the queue-limit command, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference, Release 5.x.
You use the bandwidth command to control the bandwidth allocated to the traffic classes (CoS) in the ingress queue. The bandwidth allocated to a traffic class in the ingress queue does not impact the switch. Instead, it sends the bandwidth information to the peer as an indication of the bandwidth for the traffic classes (CoS) that the peer sends. For more information about the bandwidth command, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference, Release 5.x.
You use the set cos command only on the default queue to make a port that is untrusted on the default queue.
Egress Queuing
You use egress queuing to determine how to schedule the traffic from the egress queues out of a port. The class map names represent queues and match cos represents the CoS values mapped to them. You can modify the egress class-map and match cos to achieve the desired CoS-to-queue mapping.
Note
CoS remapping is supported only in strict F1 VDCs. It is not supported in F1/M1 mixed VDCs.
Each egress port has about 0.7 MB of buffers that are distributed equally among the 8 CoS values. A CoS has approximately 0.1 MB of buffers.
The default policy egress queues are created as follows:
- The drop and no-drop CoS must be mapped to different queues.
- The priority CoS is mapped to a strict priority (SP) queue. All the nonpriority CoS values are mapped to an (DWRR) queue.
- For all the non 8e templates, second level scheduling is used.
Note ●
Egress queues are of fixed size and are not user configurable.
Each network qos policy has a corresponding default egress queuing policy (template) and is automatically activated for the system. They are the default-4q-8e-out-policy, default-4q-7e-out-policy, default-4q-6e-out-policy, and default-4q-4e-out-policy. The flexible egress queues configuration is based on these queue types—1p3q1t-8e, 1p3q1t-7e, 3p1q1t-6e, and 2p2q1t-4e.
The predefined class map names (queue names) for egress queuing are described in Table 9-2 .
You can modify an egress CoS to queue map irrespective of the ingress CoS to queue map. using the match cos command to configure the desired cos to queue mapping.
An egress queue follows a hierarchical scheduling pattern when both drop classes are present. For more information, see the “Ingress Queuing” section. For a given network qos template, the egress queuing configuration (the number of DWRR queues, number of priority queues, the scheduling hierarchy) are fixed. You can modify the bandwidth percentage, priority level, and shaper for a given port.
You use the bandwidth command to control the bandwidth allocated to an egress queue (traffic class). For more information about the bandwidth command, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference, Release 5.x.
Note
Bandwidth and priority are mutually exclusive on a class map (queue).
You use the priority command to specify that a class of traffic has low latency requirements with respect to other classes. You can configure the priority level to a traffic queue as high or low. Use the priority command to define multiple levels of a strict priority service model. For more information about the priority command, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference, Release 5.x.
The shaper can be configured with a percentage value and it can be enabled on any queue. You use the shape command to specify that a class of traffic has a maximum rate imposed on it and the outgoing traffic has a smooth output rate. In order to achieve a smooth output rate, the excess packets are retained in the queue and then scheduled for transmission later. For more information about the shape command, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference, Release 5.x.
Note
A shaper delays excess traffic, which do not confirm to the profile, by queuing it in a buffer, to shape the flow.
Licensing Requirements for Queuing and Scheduling
The following table shows the licensing requirements for this feature:
Prerequisites for Queuing and Scheduling
Queuing and scheduling have the following prerequisites:
- You must be familiar with Chapter3, “Using Modular QoS CLI”
- You are logged on to the switch.
- You are in the correct VDC. A VDC is a logical representation of a set of system resources. You can use the switchto vdc command with a VDC number.
Guidelines and Limitations
Queuing and scheduling of F1 Series cards have the following configuration guidelines and limitations:
- A queuing policy that is being activated should be consistent with the system network qos policy.
- The default queuing policy is attached to the system target (this includes all F1 module ports), which is unlike the M1 series configuration where the default-in-policy is attached exclusively to each port.
- A queuing policy attached to a given port, overrides the system queuing policy on that port.
- F1 Series modules do not support the following in a QoS policy:
Configuring Queuing and Scheduling
You configure queuing and scheduling by creating policy maps of type queuing that you apply to either traffic direction of an interface. You can configure a queuing policy by following one of these methods:
Note
When you copy an ingress or egress queuing policy, you are also copying their internal policies for the hierarchical queuing policy. Copying shorten the default policy name by stripping the default and policy substrings from it.
- User-defined policy—You can create a queuing policy that conforms to one of the system-defined queuing policy templates.
For information about configuring policy maps and class maps, see Chapter3, “Using Modular QoS CLI”
This section includes the following topics:
Configuring an Ingress Queuing Policy
You need to modify the ingress queuing policy only if you want to change the default policy that the port inherited from the system default.
You can configure an ingress queuing policy by following steps given below.
The example in this section assumes that you are copying an 8e template queuing policy.
SUMMARY STEPS
1.
qos copy policy type queuing default-4q-8e-in-policy {prefix prefix | suffix suffix}
2.
(Optional) show policy-map type queuing [policy-map-name]
4.
policy-map type queuing [policy-map-name]
5.
class type queuing [2q4t-8e-in-q-default | 2q4t-8e-in-q1]
6.
queue-limit percent [1-100]
9.
service-policy type queuing input [policy-map-name]
10.
(Optional) show policy-map type queuing [policy-map-name]
11.
(Optional) show policy-map interface ethernet [slot/port]
DETAILED STEPS
Configuring an Egress Queuing Policy
You can configure an egress queuing policy.
The example in this section assumes that you are copying a 4e template queuing policy.
SUMMARY STEPS
1.
qos copy policy type queuing default-4q-8e-out-policy | {prefix prefix | suffix suffix}
2.
show policy-map type queuing [policy-map-name]
4.
policy-map type queuing [ policy-map-name ]
5.
class type queuing [1p3q1t-8e-out-pq1 | 1p3q1t-8e-out-q-default | 1p3q1t-8e-out-q2 | 1p3q1t-8e-out-q3]
6.
bandwidth [percent {1-100} | remaining]
8.
shape [average | percent {1-100} ]
10.
service-policy type queuing output [policy-map-name]
11.
(Optional) show policy-map type queuing [policy-map-name]
DETAILED STEPS
Verifying the Queuing and Scheduling Configuration
To display the queuing policy configuration, perform one of the following tasks:
Note
The show commands display only the default policies that correspond to the active template.
When changing the network qos template, you must remove any queuing policy that is attached exclusively on an F1 module interface because the queuing policy would be inconsistent with the new network qos template.
For more information about the fields in the output from these commands, see the Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference, Release 5.x.
Configuration Examples for Queuing and Scheduling on F1 Series Modules
In this section you can find examples of configuring queuing and scheduling for the F1 Series modules.
This section includes the following topics:
- “Ingress Queuing Policy Configuration Example” section
- “Egress Queuing Policy Configuration Example” section
- “Hierarchical Queuing Policy Configuration Example” section
Ingress Queuing Policy Configuration Example
The following example shows how to configure an ingress queuing policy:
Egress Queuing Policy Configuration Example
The following example shows how to configure an egress queuing policy:
Hierarchical Queuing Policy Configuration Example
Feature History for Queuing and Scheduling for F1 Series Module
Table 9-3 lists the release history for this feature.
|
|
|
|
|---|---|---|
Feedback