Table Of Contents
Configuring Queuing and Scheduling on F-Series I/O Modules
Information About Queuing and Scheduling
Ingress Queuing
Egress Queuing
Licensing Requirements for Queuing and Scheduling
Prerequisites for Queuing and Scheduling
Guidelines and Limitations
Configuring Queuing and Scheduling
Configuring an Ingress Queuing Policy
Configuring an Egress Queuing Policy
Verifying the Queuing and Scheduling Configuration
Configuration Examples for Queuing and Scheduling on F-Series Modules
Ingress Queuing Policy Configuration Example
Egress Queuing Policy Configuration Example
Hierarchical Queuing Policy Configuration Example
Feature History for Queuing and Scheduling for F-Series Module
Configuring Queuing and Scheduling on F-Series I/O Modules
This chapter describes how to configure the QoS queuing and scheduling features on the F-Series I/O 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 F-Series Modules
•Feature History for Queuing and Scheduling for F-Series Module
Information About Queuing and Scheduling
On an F-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— Differential 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
•Egress Queuing
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:
•Different queues per drop class:
Drop queue =70% buffers; no-drop queue = 30% buffers
•Different queues for priority and nonpriority CoS in a given drop class:
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-8e-4q4q-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.
Table 9-1 Predefined Class Maps for Ingress Queuing
Ingress Policy Maps
|
Ingress Class Map Names
|
default-nq-8e-in-policy
|
2q4t-8e-in-q1 and 2q4t-8e-in-q-default
|
default-8e-4q4q-in-policy
|
4q1t-8e-4q4q-in-q1, 4q1t-8e-4q4q-in-q-default, 4q1t-8e-4q4q-in-q3, 4q1t-8e-4q4q-in-q4
|
default-nq-7e-in-policy
|
4q4t-7e-in-q1, 4q4t-7e-in-q-default, 4q4t-7e-in-q3, and 4q4t-7e-in-q4
|
default-nq-6e-in-policy
|
4q4t-6e-in-q1, 4q4t-6e-in-q-default, 4q4t-6e-in-q3, and 4q4t-6e-in-q4.
|
default-nq-4e-in-policy
|
4q4t-4e-in-q1, 4q4t-4e-in-q-default, 4q4t-4e-in-q3, and 4q4t-4e-in-q4
|
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.
By default, the queuing policy maps the priority CoS values (CoS 5-7) and non-priority CoS values (CoS 0-4) into different ingress queues (IVL). CoS to ingress queue mapping is configured from the default VDC and the configuration is applied system wide. A network administrator user role is required to change CoS to IVL.
Starting with the Cisco NX-OS 6.1 release, DSCP to IVL is supported on F2 modules, in the ingress direction, using the match dscp command with the 2q4t-8e-in-q1 class-map and the 2q4t-8e-in-q-default class-map.
Note Starting with the Cisco NX-OS 6.1(2) release, DSCP to IVL is supported on IPV6 using F2E modules.
Guidelines for the match dscp command are as follows:
•The match dscp command is applicable only to queues that have at least one CoS value associated with it. If all DSCP values are not mapped to a non-default ingress queue, the default queue should have the CoS values associated with it.
•DSCP queuing is automatically disabled when the user removes all match dscp commands (using no match statements).
•If the match dscp command is used in the 2q4t-8e-in-q1 class-map to set some DSCP values, all remaining DSCP values are automatically mapped to the default queue.
Bridged Traffic
|
When DSCP to IVL is enabled, the ingress queue selection is based on the DSCP value. However, the egress queue selection is based on the CoS value of the packet. If a CoS value does not exist, then all packets are accepted as CoS 0.
To override this behavior and use DSCP for egress queue selection, an ingress QoS policy has to be applied that matches the DSCP value and uses the set dscp value command to set the DSCP to the same value as the matched DSCP on the class-map.
|
Routed Traffic
|
When DSCP to IVL is enabled, the ingress queue selection is based on DSCP. However, the egress queue selection is based on the DSCP value, because packets are routed and the DSCP to egress queue takes place.
|
The following table contains an example of when the match dscp command is used in the 2q4t-8e-in-q1 class-map to set specific DSCP values.
Commands
|
Description
|
class-map type queuing match-any
2q4t-8e-in-q1
|
The values set by the match dscp command are displayed by the show run command.
|
class-map type queuing match-any
2q4t-8e-in-q-default
|
The remaining DSCP values (0-39, 46-63) are automatically mapped to the default queue.
The values associated with the default queue are not displayed by the show run command. These values are implicitly programmed in the hardware.
|
class-map type queuing match-any
2q4t-8e-in-q-default
|
When specific DSCP values are mapped to the default queue (2q4t-8e-in-q-default), the remaining DSCP values are automatically mapped to the default queue.
There is no restriction when specifying all of the remaining DSCP values in the default queue.
The values set by the match dscp command are displayed by the show run command.
|
class-map type queuing match-any
2q4t-8e-in-q-default
|
The DSCP values (0-39, 46-63) are automatically mapped to the default queue (2q4t-8e-in-q-default).
The values associated with the default queue are not displayed by the show run command. These values are implicitly programmed in the hardware.
|
Note Modifying the default queuing policy maps is a disruptive operation and it might 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.
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.
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 F-Series VDCs. It is not supported in F-Series/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 a DWRR queue.
•For all the non-8e templates, second level scheduling is used.
Note•Egress queues have a fixed size and are not user configurable.
•The egress port has four queues.
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-8e-4q4q-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-8e-4q4q, 1p3q1t-7e, 3p1q1t-6e, and 2p2q1t-4e.
The predefined class map names (queue names) for egress queuing are described in Table 9-2.
Table 9-2 Predefined Class Maps for Egress Queuing
Egress Policy Names
|
Egress Class Map Names
|
default-nq-8e-out-policy
|
1p3q1t-8e-out-pq1, 1p3q1t-8e-out-q2, 1p3q1t-8e-out-q3, and 1p3q1t-8e-out-q-default
|
default-8e-4q4q-out-policy
|
1p3q1t-8e-4q4q-out-pq1, 1p3q1t-8e-4q4q-out-q2, 1p3q1t-8e-4q4q-out-q3, 1p3q1t-8e-4q4q-out-q-default
|
default-nq-7e-out-policy
|
1p3q1t-7e-out-pq1, 1p3q1t-7e-out-q2, 1p3q1t-7e-out-q3, and 1p3q1t-7e-out-q-default
|
default-nq-6-out-policy
|
3p1q1t-6e-out-pq1, 3p1q1t-6e-out-pq2, 3p1q1t-6e-out-pq3, and 3p1q1t-6e-out-q-default
|
default-nq-4e-out-policy
|
2p2q1t-4e-out-pq1, 2p2q1t-4e-out-pq2, 2p2q1t-4e-out-q3, and 2p2q1t-4e-out-q-default
|
You can modify an egress CoS to queue map irrespective of the ingress CoS to queue map by 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, and 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.
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.
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.
Note A shaper delays excess traffic, that does not conform 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:
Product
|
License Requirement
|
Cisco NX-OS
|
The QoS feature does not a require license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.
|
However, using VDCs requires an Advanced Services license.
Prerequisites for Queuing and Scheduling
Queuing and scheduling have the following prerequisites:
•You must be familiar with Chapter 3 "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 F-Series modules 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 (includes all F-Series module ports), which is unlike the M1 series configuration where the default-in-policy is attached exclusively to each port.
•A queuing policy that is attached to a given port, overrides the system queuing policy on that port.
•The DSCP to egress queue selection for DSCP values 2-7 are set to be the same as the values for CoS 2-7. To change this setting, access the type QoS policy and use the set cos command to change the selected egress queue (applicable for all types of interfaces, such as access, trunk, routed, etc).
•F-Series modules do not support the following in a QoS policy:
–set discard-class or match discard-class
–set qos-group or match qos-group
•F-Series modules do not support WRED in ingress queuing policies.
•F2 modules do not support CoS-to-queue mapping changes when M1 modules are also installed in the switch.
•F-Series modules and M2 modules support shaping in the priority queue. M1 modules do not support shaping in the priority queue.
•Information about the default-nq-8e-4q4q-policy template that supports four ingress buffers.
–The default-nq-8e-4q4q-policy template is supported only with F2 modules.
–When F1 modules are online, the default-nq-8e-4q4q-policy template cannot be attached to the system qos.
–When the default-nq-8e-4q4q-policy template is attached to system qos, F1 modules are allowed to come online. However, all interfaces of the F1 modules go to the unallocated pool of the corresponding VDC.
–To make software downgrades nondisruptive, the following is required before the software downgrade:
- All user defined and cloned 8e-4q4q template queuing policies should be detached manually from all interfaces in each VDC.
- The default-nq-8e-4q4q-policy or the user defined/cloned 8e-4q4q template network-qos policy should be detached from the system qos.
- All user defined and cloned 8e-4q4q template network-qos policies should be removed manually from the default VDC.
- All user defined 8e-4q4q template queuing policies should be removed manually from all VDCs.
- Use the clear qos policies 8e-4q4q command in the default VDC to clear the default 8e-4q4q template policies. This command clears PPF (Portability Policy Format) nodes of 8e-4q4q template policies.
- After executing clear qos policies 8e-4q4q command, you must perform an in-service software downgrade (ISSD). If an ISSD is not performed, unexpected results might occur.
–The clear qos policies 8e-4q4q command is only supported in the default VDC. Using this command in the default VDC also clears the 8e-4q4q policy-maps in non-default VDCs.
–Reloading an F2 module brings up all the cleared default 8e-4q4q template related policy-maps by using the clear qos policies 8e-4q4q command.
–The default-nq-8e-4q4q-policy template is published when a software upgrade is completed.
•Information about the match dscp command:
–Supports only the ingress queues for F2 modules for the 8E template. (It does not support egress queues, M1 queues, or fabric-qos queues.)
–Supports only ingress queues that have at least one CoS value associated with it without any restriction which CoS value is used.
–Cannot be used in user defined class-maps.
–Cannot be used in a user configuration session.
–Must be disabled for ISSD. (If it is not disabled, the ISSD is disruptive).
–DSCP to IVL mapping is disabled by default.
–Queue-limit command cannot be specified based on CoS or DSCP values. The configured queue-limit sizes are applicable for both DSCP and CoS values.
–No additional statistics are generated to differentiate how many packets are matched on DSCP or CoS.
–When DSCP to IVL is enabled, an interface uses the DSCP value as trusted for IP packets and the CoS value is trusted for non-IP packets.
–No support for DSCP to IVL mapping for FabricPath interfaces and FEX port-channel interfaces.
–No support for DSCP to IVL mapping for IPv6 packets.
–DSCP to IVL mapping change is a disruptive operation and might cause BFD/Routing protocols to flap.
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:
•Copying predefined policy—You can copy a queuing policy template and modify it as needed.
Note When you copy an ingress or egress queuing policy, you are also copying the internal policies for the hierarchical queuing policy. Copying shortens 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 Chapter 3 "Using Modular QoS CLI."
This section includes the following topics:
•Configuring an Ingress Queuing Policy
•Configuring an Egress Queuing Policy
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.
Configure an ingress queuing policy:
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]
3. configure terminal
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]
7. bandwidth percent [1-100]
8. exit
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
| |
Command
|
Purpose
|
Step 1
|
qos copy policy type queuing
[default-4q-8e-in-policy {prefix prefix
| suffix suffix}
Example:
switch# qos copy policy type queuing
default-4q-8e-in-policy prefix my_
switch#
|
Copies a system-defined queuing policy and renames it with a prefix or suffix.
The policy is renamed as my_4q-8e-in-policy in this example.
|
Step 2
|
show policy-map type queuing
[policy-map-name]
Example:
switch# show policy-map type queuing
my_4q-8e-in
|
(Optional) Displays the queuing policy that you copied and renamed.
|
Step 3
|
configure terminal
Example:
switch# configure terminal
switch(config)#
|
Enters global configuration mode.
|
Step 4
|
policy-map type queuing
[policy-map-name]
Example:
switch(config)# policy-map type queuing
my_4q-8e-drop-in
switch(config-pmap-que)#
|
Configures the policy map of type queuing and enters policy-map mode for the policy map name that you specify. The policy map names can contain alphabetic, hyphen, or underscore characters, are case sensitive, and can be up to 40 characters.
|
Step 5
|
class type queuing [2q4t-8e-in-q-default
| 2q4t-8e-in-q1]
Example:
switch(config)# class type queuing
2q4t-8e-in-q-default
|
Configures the class map of type queuing and then enters policy-map class queuing mode.
|
Step 6
|
queue-limit percent [1-100]
Example 1:
switch(config)# class type queuing
2q4t-8e-in-q-default
switch(config-pmap-c-que)# queue-limit
40
Example 2:
switch(config)# class type queuing
2q4t-8e-in-q1
switch(config-pmap-c-que)# queue-limit
60
|
Sets the queue limit for the queue. The range is from 1 to 100.
Note The total queue limit for all the queues in the policy cannot exceed 100.
In this example, the queue limit is set to 40 percent in the 2q4t-8e-in-q-default and 60 percent in 2q4t-8e-in-q1.
|
Step 7
|
bandwidth percent [1-100]
Example:
switch(config-pmap-c-que)# bandwidth
percent 10
switch(config-pmap-c-que)#
|
Allocates the bandwidth to the CoS values mapped to the queues for exchanging with the peer. The range is from 1 to 100.
The bandwidth is set to 10 percent in this example.
|
Step 8
|
exit
Example:
switch(config-cmap-que)# exit
switch(config)#
|
Exits policy-map queue mode and enters configuration mode.
|
Step 9
|
service-policy type queuing input
[policy-map-name]
Example:
switch(config)# interface ethernet 5/5
switch(config-if)# service-policy type
queuing input my_4q-8e-in
switch(config-if)#
|
Applies a policy to an interface.
|
Step 10
|
show policy-map type queuing
[policy-map-name]
Example:
switch# show policy-map type queuing
default-4q-4e-in-policy
|
(Optional) Displays information about all configured policy maps or a selected policy map of type queuing.
|
Step 11
|
show policy-map interface ethernet
[slot/port]
Example:
switch# show policy-map interface
ethernet 1/5
|
(Optional) Displays information about the service policy on an Ethernet interface.
|
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]
3. configure terminal
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]
7. priority level{1 | 2}
8. shape [average | percent {1-100}]
9. exit
10. service-policy type queuing output [policy-map-name]
11. (Optional) show policy-map type queuing [policy-map-name]
DETAILED STEPS
| |
Command
|
Purpose
|
Step 1
|
qos copy policy type queuing
default-4q-8e-out-policy {prefix prefix
| suffix suffix}
Example:
switch# qos copy policy type queuing
default-4q-8e-out-policy prefix my_
switch#
|
Copies a system-defined queuing policy and renames it with a prefix or suffix.
The policy is renamed as my_4q-8e-out-policy in this example.
|
Step 2
|
show policy-map type queuing
[policy-map-name]
Example:
switch# show policy-map type queuing
my_4q-8e-out-policy
|
(Optional) Displays the queuing policy that you copied and renamed.
|
Step 3
|
configure terminal
Example:
switch# configure terminal
switch(config)#
|
Enters global configuration mode.
|
Step 4
|
policy-map type queuing
[policy-map-name]
Example:
switch(config)# policy-map type queuing
my_4q-8e-out-policy
switch(config-pmap-que)#
|
Configures the policy map of type queuing and enters policy-map mode for the policy-map name that you specify. Policy-map names can contain alphabetic, hyphen, or underscore characters, are case sensitive, and can be up to 40 characters.
|
Step 5
|
class type queuing [1p3q1t-8e-out-pq1 |
1p3q1t-8e-out-q-default |
1p3q1t-8e-out-q2 | 1p3q1t-8e-out-q3]
Example:
switch(config)# class type queuing
1p3q1t-8e-out-pq1
switch(config-pmap-c-que)#
|
Configures the class map of type queuing and then enters policy-map class queuing mode.
|
Step 6
|
bandwidth {percent {1-100}| remaining}
Example:
switch(config-pmap-c-que)# bandwidth
percent 25
switch(config-pmap-c-que)#
|
Allocates the bandwidth in all ingress packets to the value specified. The range is from 1 to 100. Alternatively, absolute values in Gbps, Mbps, Kbps can also be specified.
The bandwidth is set to 25 percent in this example.
|
Step 7
|
priority level {1 | 2}
Example:
switch(config-cmap-que)# priority level
1
switch(config-cmap-que)#
|
Marks the priority level of the traffic queue. 1 stands for the highest priority and 2 stands for the lowest priority.
The priority level is set to 1 in this example.
|
Step 8
|
shape percent [average | percent
{1-100}]
Example:
switch(config-cmap-que)# shape 50000 bps
switch(config-cmap-que)#
|
Shapes the traffic rate from a queue. The range is from 80000 bits per second to 10 Gigabytes per second.
The shaper is set to 50000 bits per second in this example.
|
Step 9
|
exit
Example:
switch(config-cmap-que)# exit
switch(config)#
|
Exits policy-map queue mode, and enters global configuration mode.
|
Step 10
|
service-policy type queuing output
[policy-map-name]
Example:
switch(config)# interface ethernet 5/5
switch(config-if)# service-policy type
queuing input my_4q-8e-out
switch(config-if)#
|
Applies a policy to an interface.
|
Step 11
|
show policy-map type queuing
[policy-map-name]
Example:
switch# show policy-map type queuing
my_4q-8e-out-policy
|
(Optional) Displays information about all configured policy maps or a selected policy map of type queuing.
|
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.
Command
|
Purpose
|
show queuing interface ethernet
|
Displays information about whether the queuing policy is applied correctly to the module.
|
show class-map type queuing
|
Displays information about all configured class maps or a selected class map of type queuing.
|
show policy-map type queuing
|
Displays information about all configured policy maps or a selected policy map of type queuing.
|
When changing the network qos template, you must remove any queuing policy that is attached exclusively on an F-Series 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.
Configuration Examples for Queuing and Scheduling on F-Series Modules
In this section you can find examples of configuring queuing and scheduling for the F-Series modules.
This section includes the following topics:
•Ingress Queuing Policy Configuration Example
•Egress Queuing Policy Configuration Example
•Hierarchical Queuing Policy Configuration Example
Ingress Queuing Policy Configuration Example
The following example shows how to configure an ingress queuing policy:
policy-map type queuing p-4que-7e-drop-in
class type queuing 4q4t-7e-in-q1
class type queuing 4q4t-7e-in-q2
class type queuing 4q4t-7e-in-q3
policy-map type queuing p-4que-7e-ndrop-in
class type queuing 4q4t-7e-in-q4
policy-map type queuing p-4que-7e-in
class type queuing c-4q-7e-drop-in
service-policy type queuing p-4que-7e-drop-in
class type queuing c-4q-7e-drop-in
service-policy type queuing p-4que-7e-ndrop-in
Egress Queuing Policy Configuration Example
The following example shows how to configure an egress queuing policy:
policy-map type queuing p-4que-6e-drop-out
class type queuing 1q3p1t-6e-out-pq1
class type queuing 1q3p1t-6e-out-q4
bandwidth remaining percent 100
policy-map type queuing p-4que-6e-ndrop-out
class type queuing 1q3p1t-6e-out-pq2
class type queuing 1q3p1t-6e-out-pq3
policy-map type queuing p-4que-6e-out
class type queuing c-4q-6e-drop-out
service-policy type queuing p-4que-6e-drop-out
class type queuing c-4q-6e-ndrop-out
service-policy type queuing p-4que-6e-ndrop-out
Hierarchical Queuing Policy Configuration Example
The following example shows how to configure a hierarchical queuing policy.
policy-map type queuing inner-policy-1
class type queuing 1p3q1t-out-q1
class type queuing 1p3q1t-out-q2
policy-map type queuing inner-policy-2
class type queuing 1p3q1t-out-q3
class type queuing 1p3q1t-out-q4
class-map type queuing drop-class
match class-map 1p3q1t-out-q1
match class-map 1p3q1t-out-q2
class-map type queuing nodrop-class
match class-map 1p3q1t-out-q3
match class-map 1p3q1t-out-q4
policy-map type queuing example-hierarchical-policy
class type queuing drop-class
service-policy type queuing inner-policy-1
service-policy type queuing inner-policy-2
Feature History for Queuing and Scheduling for F-Series Module
Table 9-3 lists the release history for this feature.
Table 9-3 Feature History for Queuing
Feature Name
|
Releases
|
Feature Information
|
Support for four ingress buffers.
|
6.1(3)
|
Support for default-nq-8e-4q4q-policy template that supports four ingress buffers.
|
DSCP mapping for F2 modules
|
6.1(1)
|
Support for DSCP mapping for F2 modules
|
Scheduling and Queuing for F1 Series Modules
|
5.1(1)
|
This chapter was added. (Chapter title subsequently changed to accommodate other F-Series Modules.)
|
Feedback