Cisco Systems 4500 Priority Queuing

37-80
Software Configuration Guide—Release 15.0(2)SG
OL-23818-01
Chapter 37 Configuring Quality of Service
Configuring QoS on Supervisor Engine 6-E, Supervisor Engine 6L-E, Catalyst 4900M, and Catalyst 4948E
Class prec3
bandwidth 100000 (kbps)
When a queuing class is configured without any explicit share/bandwidth configuration, because the
queue is not guaranteed any minimum bandwidth, the hardware queue is programmed to get a share of
any unallocated bandwidth on the port as shown in the following example.
If there is no bandwidth remaining for the new queue or if the unallocated bandwidth is not sufficient to
meet the minimum configurable rate (32 kbps) for all queues which do not have any explicit
share/bandwidth configuration, then the policy association is rejected.
For example, there are two queues as follows:
policy-map queue-policy
class q1
bandwidth percent 10
class q2
bandwidth percent 20
The bandwidth allocation for the queues is as follows:
q1 = 10%
q2 = 20%
class-default = 70%
Similarly, when another queuing class (say q3) is added without any explicit bandwidth (a shape
command), then the bandwidth allocation is as follows:
q1 = 10%
q2 = 20%
q3 = min(35%, q3-shape-rate)
class-default = max(35%, (100 - (q1 + q2 + q3 )))
Priority Queuing
On Catalyst 4900M, Catalyst 4948E, Supervisor Engine 6-E, and Supervisor Engine 6L-E, you can
configure only one transmit queue (on a port) as strict priority (termed low latency queue, or LLQ).
LLQ provides strict-priority queuing for a traffic class. It enables delay-sensitive data, such as voice, to
be sent before packets in other queues. The priority queue is serviced first until it is empty or until it is
under its shape rate. Only one traffic stream can be destined for the priority queue per class-level policy.
You enable the priority queue for a traffic class with the priority policy-map class configuration
command at the class mode.
An LLQ can starve other queues unless it is rate-limited. Catalyst 4900M, Catalyst 4948E, Supervisor
Engine 6-E, and Supervisor Engine 6L-E do not support conditional policing where a two-parameter
policer (rate, burst) becomes effective when the queue is congested (based on queue length). However,
it supports application of an unconditional policer to rate-limit packets enqueued to the strict priority
queue.
When a priority queue is configured on one class of a policy map, only bandwidth remaining is accepted
on other classes, guaranteeing a minimum bandwidth for other classes from the remaining bandwidth of
what is left after using the priority queue. When a priority queue is configured with a policer, then either
bandwidth or bandwidth remaining is accepted on other classes.
Note Use bandwidth or bandwidth remaining on all classes. You cannot apply bandwidth on one class and
bandwidth remaining on another class within a policy map.