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.

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. Currently, the device supports two priority levels: level 1 (high) and level 2 (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.

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:

• Conditional traffic policing, for example:

  policy-map my_policy
    class voice
     priority 400000   <<< Priority queue conditionally policed to 400M
    class gold
     bandwidth 400000 <<< 400M minimum guaranteed to class gold
  

  With conditional traffic policing on the queue, you run the risk of sudden degradation in priority service when an interface becomes congested. You can go from an instance of a priority class using the entire link to suddenly traffic being policed to the configured value. You need to know the available bandwidth and use some form of admission control to ensure that your offered loads do not exceed the available bandwidth.

  Note	With the conditional policing, traffic policing does not engage unless the interface is congested.

• 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.

• Absolute priority queue (no traffic policing)

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