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 num- ber may show fluctuating values. As long as there are no drops, you're in good shape. Monitoring QoS 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 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 behav- ing properly, this line will show you how much bandwidth has been needed for the default queue. It also shows you the drop rate, which should be zero. If there is one queue where it's permissible to drop packets, it's this one. This is the queue where all your noncritical traffic goes. If you need to drop packets due to congestion, it should be the noncritical traffic that suffers, not the important stuff like voice calls. Troubleshooting a Converged Network Dropping packets within specific queues can be hard to diagnose. After you've worked with a converged network for a while, though, you will get a feel for how the queues should behave. While every network is different, here are some common symptoms to look out for. Incorrect Queue Configuration When all the queues are configured correctly, none of them should drop packets when the link is congestion-free. When congestion occurs, packets should be dropped