Multi-Level Priority Queues

The Multi-Level Priority Queues (MPQ) feature allows you to configure multiple priority queues for multiple traffic classes by specifying a different priority level for each of the traffic classes in a single service policy map. You can configure multiple service policy maps per device. Having multiple priority queues enables the device to place delay-sensitive traffic (for example, voice) on the outbound link before delay-insensitive traffic. As a result, high-priority traffic receives the lowest latency possible on the device.

Prerequisites for Multi-Level Priority Queues

You must configure traffic classes using the class-map command.

Restrictions for Multi-Level Priority Queues

  • The Bandwidth kbps and percent command cannot co-exist with strict priority or priority level in the same policy-map. So, a check is added to ensure only a policer with drop action, along with priority is allowed as a conditional priority.

  • You cannot configure both the priority command and the priority level command for two different classes in the same policy map. For example, the device does not accept the following configuration:
    
    Device> enable
    Device# configure terminal
    Device(config)# policy-map Map1
    Device(config-pmap)# class Bronze
    Device(config-pmap-c)# priority level 1
    Device(config-pmap-c)# exit
    Device(config-pmap)# class Gold
    Device(config-pmap-c)# priority 1000
    Device(config-pmap-c)# end
    

    Note

    The priority rate command is not supported, instead you can use proirity cir command on the Cisco RSP3 Module.


  • You cannot specify the same priority level for two different classes in the same policy map. For example, the device does not accept the following configuration:
    
    Device> enable
    Device# configure terminal
    Device(config)# policy-map Map1
    Device(config-pmap)# class Bronze
    Device(config-pmap-c)# priority level 1
    Device(config-pmap-c)# police cir percent 30
    Device(config-pmap-c)# exit
    Device(config-pmap)# class Gold
    Device(config-pmap-c)# priority level 1
    Device(config-pmap-c)# police cir 10000
    Device(config-pmap-c)# end
    
  • You cannot configure the default queue as a priority queue at any level.

  • You cannot configure the bandwidth command and multi-level priority queues on the same class. For example, the device rejects the following configuration:
    
    policy-map P1
     class C1
      priority level 1
      bandwidth 200
    
  • You cannot configure the shape command and multi-level priority queues on the same class. For example, the device rejects the following configuration:
    
    policy-map P1
     class C1
      priority level 1
      shape average 56000
    
  • To convert a one-level (flat) service policy with multiple priority queues configured to a hierarchical multi-level priority queues service policy, you must first detach the flat service policy from the interface using the no service-policy command and then add a child policy map to it.

  • The sum of the police committed information rate (cir), which can be specified as in kilobits per second (kbps) or as a percentage, configured at the two priority levels cannot exceed the interface bandwidth. Any policy that has a police cir sum greater than the interface bandwidth will be rejected. For example, the following policy will be rejected by a 1-gigabit (Gb) interface because the sum of the police cir (600 Mb + 700 Mb) is greater than 1 Gb.
    
    policy-map new
     class qos-group 1
      priority level 1
      police cir 600000000
     class qos-group 2
       priority level 2
       police cir 700000000
  • We recommend not to use MPQ at the logical level, that is, under the class-map containing match for the VLANs .

Information About Multi-Level Priority Queues

Benefits of Multi-Level Priority Queues

The MPQ feature allows you to configure multiple priority queues for multiple traffic classes by specifying a different priority level for each of the traffic classes in a single service policy map. You can configure multiple service policy maps per device.

Previously, devices could have only one strict priority queue per policy map for all delay-sensitive traffic—the device associated all priority traffic with this one single priority queue. However, having only one priority queue can cause significant delay in delivering traffic, especially if the device sends high-priority traffic (for example, voice) behind low-priority traffic (for example, video). Using class-based weighted fair queueing (CBWFQ) to reduce delay by heavily weighting one queue can affect the granularity of bandwidth allocations to the other queues. The MPQ feature addresses these issues and improves latency.

Functionality of Multi-Level Priority Queues

The priority command is used to specify that a class of traffic has latency requirements with respect to other classes. For multiple priority queues, you can use the priority level command to configure a level of priority service on a class in a policy map. The device supports seven priority levels: level 1 (high) to level 7 (low). The device places traffic with a high-priority level on the outbound link ahead of traffic with a low-priority level. High-priority packets, therefore, are not delayed behind low-priority packets.

The device services the high-level priority queues until empty before servicing the next-level priority queues and non-priority queues. While the device services a queue, the service rate is as fast as possible and is constrained only by the rate of the underlying link or parent node in a hierarchy. If a rate is configured and the device determines that a traffic stream has exceeded the configured rate, the device drops the exceeding packets during periods of congestion. If the link is currently not congested, the device places the exceeding packets onto the outbound link.

When configuring MPQ on different traffic classes in a policy map, you must specify different priority levels for the traffic classes. For example, configure one traffic class to have priority level 2 and another class to have priority level 1.


Note

In a hierarchical MPQ configuration in which all traffic is sent through the level-2 priority queue only, the traffic sent through the level-2 priority queue receives the same treatment as the traffic sent through the level-1 priority queue.


You cannot configure the priority command and the priority level command on different classes in the same policy map.

Traffic Policing and Multi-Level Priority Queues

Bandwidth guarantees can be given to other classes only if traffic policing is enabled on the priority queue.

Using the priority and police commands, multi-level priority queues can be configured to police traffic in one of the following ways:

  • Unconditional traffic policing, for example:

    
    policy-map my_policy
      class voice
       priority           <<< Indicates priority scheduling
       police 400000000   <<< Traffic policed to 400M
      class gold
       bandwidth 400000  <<<400M minimum guaranteed to class gold
    

    The priority class is configured with an “always on” (unconditional) policer. The priority class is always policed to the configured value regardless of whether the interface is congested. The advantage of an unconditional policer is that you always know how much priority traffic will be offered to the downstream devices, thus making your bandwidth planning much simpler. This is the recommended choice.


    Note

    The following is an example of priority policing on the Cisco ASR 900 RSP3 Module.
    
    policy-map my_policy
      class voice
       priority 400000   <<< Indicates priority scheduling and traffic shape rate
      class gold
       bandwidth 400000  <<< Minimum guaranteed to class gold
    
  • Absolute priority queue (no traffic policing)

    If traffic policing is not configured, the priority traffic may consume the entire interface bandwidth.

How to Configure Multi-Level Priority Queues

Configuring Multi-Level Priority Queues in a Policy Map

Before you begin

The traffic classes, class maps, and policy maps must exist.

Procedure


Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

configure terminal

Example:


Device# configure terminal

Enters global configuration mode.

Step 3

policy-map policy-name

Example:


Device(config)# policy-map Premium

Creates or modifies a policy map and enters policy-map configuration mode.

  • Enter the name of the policy map.

Step 4

class class-name

Example:


Device(config-pmap)# class business

Specifies a traffic class and enters policy-map class configuration mode.

  • Enter the name of a previously configured traffic class.

Step 5

priority level level

Example:


Device(config-pmap-c)# priority level 7

Assigns priority to a traffic class at the priority level specified.

  • Enter the level of priority assigned to the priority class.

    Valid values are from 1 (high priority) to 7 (lowest priority).

Note 

Do not specify the same priority level for two different classes in the same policy map.

Step 6

police cir bps

Example:


Device(config-pmap-c)# police cir 8000 

(Optional) Configures traffic policing based on a bits per second (bps) rate.

  • cir is the committed information rate and is based on the interface shape rate. This keyword indicates an average rate at which the policer meters traffic.

  • bps specifies the average rate in bits per second (bps). Valid values are from 64000 to 10000000000 bps.

Step 7

police cir percent percent

Example:


Device(config-pmap-c)# police cir percent 20 

(Optional) Configures traffic policing based on a percentage of bandwidth available on the interface.

  • cir is the committed information rate and is based on the interface shape rate. This keyword indicates an average rate at which the policer meters traffic.

  • percent percent indicates to use the percentage of available bandwidth specified in percent to calculate the CIR. Valid values are from 1 to 100.

Step 8

end

Example:


Device(config-pmap-c)# end

(Optional) Exits policy-map class mode.


Verifying Multi-Level Priority Queues

Procedure


Step 1

enable

Example:


Device> enable

Enables privileged EXEC mode.

  • Enter your password if prompted.

Step 2

show policy-map interface type number

Example:


Device# show policy-map interface serial4/0/0

Displays the packet statistics of all classes that are configured for all service policies either on the specified interface or subinterface or on a specific PVC on the interface.

  • Enter the interface type and number.

Step 3

exit

Example:


Device# exit

(Optional) Exits privileged EXEC mode.


Configuration Examples for Multi-Level Priority Queues

Example: Configuring Multi-Level Priority Queues

The following example shows how to configure multiple priority queues with 2 level priority. The policy map named Business has two traffic classes: Bronze and Gold. Bronze traffic has a level 2 (low) priority, whereas Gold traffic has a level 1 (high) priority. To prevent bandwidth starvation of Bronze traffic, the Gold traffic is policed at 30 percent of the interface bandwidth.


Device> enable
Device# configure terminal
Device(config)# policy-map Business
Device(config-pmap)# class Bronze
Device(config-pmap-c)# priority level 2
Device(config-pmap-c)# police cir 1000
Device(config-pmap-c)# exit
Device(config-pmap)# class Gold
Device(config-pmap-c)# priority level 1
Device(config-pmap-c)# police cir percent 30
Device(config-pmap-c)# end

Note

Although a policer is not required, configure policing for priority traffic to prevent bandwidth starvation of low-priority traffic. When policing is configured, the traffic rate is policed at the police rate for each of the priority queues.


The following example shows how to configure multiple priority queues with 7 level priority. The policy map named Business has seven traffic classes: Platinum, Gold, Silver, Bronze, Iron, Aluminium, and Steel. Steel traffic has a level 7 (lowest) priority, whereas Platinum traffic has a level 1 (highest) priority. To prevent bandwidth starvation, the Platinum and Gold traffic is policed at 30 percent and 20 percent respectively, of the interface bandwidth.
Device> enable
Device# configure terminal
Device(config)# policy-map Business
Device(config-pmap)# class Platinum
Device(config-pmap-c)# priority level 1
Device(config-pmap-c)# police cir percent 30
Device(config-pmap-c)# end
Device(config-pmap)# class Gold
Device(config-pmap-c)# priority level 2
Device(config-pmap-c)# police cir percent 20
Device(config-pmap-c)# end
Device(config-pmap)# class Silver
Device(config-pmap-c)# priority level 3
Device(config-pmap-c)# police cir 1000
Device(config-pmap-c)# end
Device(config-pmap)# class Bronze
Device(config-pmap-c)# priority level 4
Device(config-pmap-c)# end
Device(config-pmap)# class Iron
Device(config-pmap-c)# priority level 5
Device(config-pmap-c)# end
Device(config-pmap)# class Aluminum
Device(config-pmap-c)# priority level 6
Device(config-pmap-c)# end
Device(config-pmap)# class Steel
Device(config-pmap-c)# priority level 7
Device(config-pmap-c)# end

Example: Verifying Multi-Level Priority Queues

The following is partial sample output from the show policy-map interface command.


Device# show policy-map interface Gigbit/TenGig 2/1/0
 
Gigbit/TenGig 2/1/0
Service-policy output: P1
Queue statistics for all priority classes:
.
.
.
Class-map: Gold (match-all)
0 packets, 0 bytes				/*Updated for each priority level configured.*/
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 2
Priority: 0 kbps, burst bytes 1500, b/w exceed drops: 0
Priority Level 2:
0 packets, 0 bytes

Priority Propagation

When priority is not configured on any queue, all queues within a sub-channel are treated equally. Priority can be set for any queue within a sub-channel. In that case, the queue is treated according to its priority. However, this priority is not considered when scheduling is done across multiple sub-channels. In other words, the priority defined at the queue level is lost when packets from different sub-channels are scheduled at the egress. Effective Cisco IOS-XE Release 3.15.0S, priority defined at the PHB (queue) level is propagated for scheduling across sub-channel levels.

A channel is the parent stream for the sub-channel, which in turn is the parent for the queue. During priority propagation of a child stream, the parent gets the priority for that child in its own expedite or normal group.


Note

At queue-level, scheduling in expedite or normal group works in Strict Priority Mode, whereas at sub-channel level scheduling occurs in a round robin manner.


Restrictions for the Priority Propagation

  • Priority Propagation is supported only for per-hop behavior (PHB)-level classes.

  • Priority Propagation works only for the sub-channels within same group (expedite/normal).

  • Priority levels for queue-level classes across different sub-channels are treated the same when propagated at the sub-channel level.

  • A priority propagated queue doesn’t get priority over queues of other sub-channels that are configured as an expedite queue and CIR is configured on them (that is, priority is set on the sub-channel).

  • Priority propagated queue with CIR configured on its sub-channel competes with HPCT queue traffic.

Hardware Limitation

There’s a hardware limitation where you can’t have a priority child to a non-priority parent. And if the queue is configured as expedite and if its parent sub-channel isn’t, then jitter occurs on the priority queue due to the arbitration latencies at the sub-channel level.

The hardware limitation is applicable on the following scenarios:

  • Two-level Hierarchical QoS (H-QoS) with parent and child policy-map is configured.

  • Parent child policy-map with a class-default and a shaper of any value.

  • A child policy-map configured with priority level for a priority class and a class-default to serve a non-priority traffic.

  • When congestion is created by sending more traffic (greater than shaper value) to non-priority class along with priority traffic to the policy-map.

To overcome this hardware limitation, you can have different services for priority and non-priority traffic and you must configure the parent (class-default with shaper) at the interface-level and need to separate the priority, and non-priority traffic to flow through different services by implementing Priority Propagation.

Configuring the Priority Propagation

Procedure


Step 1

enable

Example:

Router> enable

Enables privileged EXEC mode.

Step 2

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

policy-map policy-name

Example:

Router(config)# policy-map foo

Creates or specifies the name of the traffic policy and enters policy-map configuration mode.

Step 4

class {class-name | class-default}

Example:

Router(config-pmap)# class bar

Specifies the name of a traffic class and enters policy-map class configuration mode.

Step 5

priority level level

Example:

Router(config-pmap-c)# priority level 2

Configures multiple priority queues

level —(Optional) Defines multiple levels of a strict priority service model. When you enable a traffic class with a specific level of priority service, the implication is a single priority queue associated with all traffic enabled with the specified level of priority service.

Valid values are from 1 (high priority) and 2 (low priority).The default value is 1.


Verifying the Priority Propagation Configuration


Router# show policy-map root 
  Policy Map root
    Class class-default
      Shape average 100Mb

Router# show policy-map q1 
    Class dscp1
        Priority level 2
Router# show policy-map q2
    Class dscp1

Router# show running-config interface gigabitEthernet 0/4/3 
Building configuration...

Current configuration: 408 bytes
!
interface GigabitEthernet0/4/3
 no ip address
 negotiation auto
 service-policy output root
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  service-policy output q1        => vlan 10 dscp 1 gets priority over vlan 100 dscp 1 traffic 
  bridge-domain 10
 !
 service instance 100 ethernet
  encapsulation dot1q 100
  rewrite ingress tag pop 1 symmetric
  service-policy output q2 
  bridge-domain 100
 !
end

Additional References for Multi-Level Priority Queues

Related Documents

Related Topic

Document Title

QoS commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Cisco IOS Quality of Service Solutions Command Reference

Priority queues, creating classes, class maps, and policy maps

“Applying QoS Features Using the MQC” module

Technical Assistance

Description

Link

The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

http://www.cisco.com/cisco/web/support/index.html