lets us know how much of the queue is being used. This information is also shown later in the output as the 5 minute rate. Under the Queuing paragraph, we can see that this map is using the strict priority queue. Beneath that is a report of the queue size. Lastly, the number of packets and bytes dropped is reported. This should always be o/o. If your traffic spikes beyond your planned levels, however, you may start to drop packets. When you're dealing with voice calls in the strict priority queue, dropped packets result in distorted or choppy voice quality and unhappy users. The information for the next queue is a little different. Because this is not the strict priority queue, the queue is described as we've designed it: Class-map: Voice-Control (match-all) 793462 packets, 161097064 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 3 Queueing Output Queue: Conversation 265 Bandwidth 5 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 793462/161097064 (depth/total drops/no-buffer drops) 0/0/0 In this example, the five-minute offered rate is zero. This is call control, and packets should only hit this queue when calls are set up or torn down. If no calls have been started or completed in the last five minutes, this rate could be valid. Further down, we can see that 5 percent of the bandwidth has been allocated for this queue. The last line again shows that no packets have been dropped for this queue. The depth is the number of packets currently in the queue. On busy links, this number may show fluctuating values. As long as there are no drops, you're in good shape. Skipping down to the last queue, we get yet another view: Class-map: class-default (match-any) 2243454 packets, 2851898036 bytes 5 minute offered rate 52000 bps, drop rate 0 bps Monitoring QoS Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0 The first line in bold should be closely monitored. If all your other queues are behaving properly, th