ile it's performing well, the five-minute offered rate is only 1,000 bps. The queue has been allocated 10 percent of the link. If we make this queue's allocation smaller, the default queue might stop dropping packets. (Actually, given the amount of traffic on the link, in this case this is unlikely. The five-minute offered rate in the class-default queue is 887,000 bps. That's almost two-thirds of a T1 in and of itself!) Troubleshooting a Converged Network Priority Queue Too Small The rate for the Voice-RTP queue seems stable at about 80 Kbps. For fun, I'll lower the size of the priority queue to 64 Kbps: R1# conf t R1(config)# policy-map WAN R1 (config-pmap)# class Voice-RTP (config-pmap-c)# priority 64 Now, let's take another look at the queues using the show policy-map interface interface# command: R1# sho policy-map interface s0/1 Serial0/1 Service-policy output: WAN Class-map: Voice-RTP (match-any) 19682025 packets, 4014346028 bytes 5 minute offered rate 79000 bps, drop rate 17000 bps Match: ip precedence 5 19682025 packets, 4014346028 bytes 5 minute rate 79000 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 64 (kbps) Burst 1600 (Bytes) (pkts matched/bytes matched) 19682025/4014346028 (total drops/bytes drops) 1538/313752 Look at the drop statistics. The first line in bold shows a drop rate of 17,000 bps. This is a severe problem indicating that the queue is too small. This line is telling us that the queue offered up 79,000 bps, but had to drop 17,000 bps. To prevent packets from being dropped, the queue should be set to a minimum of 79,000 + 17,000 = 90,000 bps. If you see anything other than zero in the drop rate section of this output, you've got a problem. The last line of output shows the total drops and bytes dropped. This is a counter, SO it will display an incrementing total until the interface is reset, or the counters are cleared. To illustrate this point, I've let the router run with the priority queue set too small for an hour, then set the bandwidth value back to 128 Kbps.