 4690398 bytes 5 minute offered rate 1000 bps, drop rate 0 bps Match: access-group 101 79255 packets, 4690398 bytes 5 minute rate 1000 bps Queueing Output Queue: Conversation 266 Bandwidth 10 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 78903/4669112 (depth/total drops/no-buffer drops) 0/0/0 Class-map: class-default (match-any) 23750755 packets, 2030244008 bytes 5 minute offered rate 887000 bps, drop rate 4000 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 12/16501/0 If users are complaining at this point, there are a few things to consider: The link may be saturated, in which case it should be replaced with a larger link. Some traffic in the class-default queue may need to be prioritized above this queue. One or more of the queues may not be configured appropriately. Look at the HTTP queue. While 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 allo- cation smaller, the default queue might stop dropping packets. Actually, given the amount of traffic on the link, in this case, that 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! 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 Troubleshooting a Converged Network Now, let's take another look at the queues using the show policy-map interface inter face# 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 Band