lt 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 bps, drop rate 0 bps Match: ip precedence 5 3150111 packets, 642496644 bytes 5 minute rate 81000 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 256 (kbps) Burst 6400 (Bytes) (pkts matched/bytes matched) 3150111/642496644 (total drops/bytes drops) 0/0 This queue looks healthy, and it is, for all practical purposes. The problem is far subtler than can be determined from the numbers. The queues are serviced by something called the scheduler. The scheduler serves each queue according to its size and its position in the configuration. The priority queue is always serviced first. Only when the priority queue is empty will other queues be serviced. I have seen problems on large links such as DS3s when the priority queue is set to a very high level. For example, setting the priority queue near 75 percent of the total link speed causes the queues beneath the priority queue to be starved. In other words, the scheduler spends SO much time servicing the priority queue that, even if there is little Troubleshooting a Converged Network traffic, the other queues never get serviced. This results in packets being dropped in the lower queues, even if there is plenty of capacity to serve them all. Try to keep the priority queue near the level of the expected traffic peaks. Nonpriority Queue Too Small Our example is using a T1, and the Voice-Control queue is set to use 5 percent of the link. Five percent of 1.544 Mbps is about 77 Kbps. Here, I've increased the call-control traffic to exceed the queue size. I'm now pushing 90 Kbps through this queue: Class-map: Voice-Control (match-all) 213781 packets, 40614182 bytes 5 minute offered rate 90000 bps, drop rate 0 bps Match: ip precedence 3 Queueing Output Queue: Conversation 265 Bandwidth 5 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 