r- cent of all packets dropped. I'd say we've found our problem. This link is SO saturated that more than 1 out of every 10 packets is being discarded. One out of 10. It's no wonder users are complaining! Chapter 31: The Congested Network A total of 11.47 percent might not seem like a lot of dropped packets, but remember that VoIP cannot stand to have packets dropped. Even 1 percent would be a problem for VoIP. And for protocols that can recover lost packets, the result is a perceived slowdown. So, what should your dropped-packets counters look like? In a perfect world, they should be zero. More practically, they should not increment as you watch them, and they should be as close as possible to 0 percent of your total pack- ets sent. If you're dropping even 1 percent of your packets over a serial link, you've got a congestion problem. Now that we know what the problem is, we need to monitor the link over time. We want to ensure that all those packets weren't dropped in the last 10 minutes (though that's unlikely given the high numbers). It is probably safe to make some assump- tions, though. If you've configured MRTG to monitor usage for you, the historical information it provides can help, and the pretty graphs make explaining things to the executives a whole lot easier. Figure 31-3 shows that the link is saturated pretty much all day long. The problem starts roughly when the users come into work, and ends roughly when they all go home. See how the graph peaks and then runs flat up near 1,600 Kbps all day, every day? This link is oversubscribed. 1600.0 k 1200.0 k 800.0 k 400.0 k 0.0 k Figure 31-3. One week's historical MRTG graph for our link Resolving the Problem So, what do we do? Can QoS save the day? Well, yes and no. QoS is, in fact, already running on the link (weighted fair queuing), but it's making certain assumptions as to what traffic should be prioritized. WFQ is also only running in one direction (luckily, the direction in which we need it to be running, which is the direction that most of the data i