 I waited five minutes to let the counters settle, and then executed the command again: R1# sho policy-map interface s0/1 Serial0/1 Service-policy output: WAN Class-map: Voice-RTP (match-any) 20049682 packets, 4089333416 bytes 5 minute offered rate 79000 bps, drop rate 0 bps Match: ip precedence 5 Chapter 32: The Converged Network 20049682 packets, 4089333416 bytes 5 minute rate 79000 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 128 (kbps) Burst 3200 (Bytes) (pkts matched/bytes matched) 20049682/4089333416 (total drops/bytes drops) 78648/16044192 The drop rate in the first bold line is now zero, as it should be. However, the last line still shows some very high numbers. If I were to see something like this on a nor- mally healthy link, I would suspect that one of two things had happened: Someone altered the configuration like I just did, and did not clear the counters after resolving the issue. There was a surge of traffic in this queue that exceeded the queue's configured bandwidth. In either case, you should try to determine what's happened. If there was a surge of traffic in the priority queue, it's possible that either there were more active phone calls than you anticipated, or the active calls were not using the proper codec. Even worse, packets might be getting marked as IP precedence 5 when they shouldn't be. If the priority queue is saturated, even if there is additional bandwidth available, packets will still be dropped from the priority queue. The priority queue differs from the other queues in that it will not use the remaining available bandwidth on the link for overflow. When this queue is too small, packets will be dropped. Priority Queue Too Large When the priority queue is too large, it can affect network performance. However, this problem can be very difficult to diagnose. Here, the priority queue has been set to 256 Kbps, but the traffic hitting the queue is only about 80 Kbps: Class-map: Voice-RTP (match-any) 3150111 packets, 642496644 bytes 5 minute offered rate 81000 