ackets 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 assumptions, though. If you've configured MRTG to monitor usage for you, the historical informa- tion it provides can help, and the pretty graphs make explaining things to the executives a whole lot easier. Figure 33-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 Figure 33-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 (WFQ), but it's making certain assumptions as to which 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 is flowing). We've already talked about what QoS cannot do. One of the big things that it cannot do is resolve a need for more bandwidth. This link is clearly in need of a larger pipe, because we're dropping more than 10 percent of all packets sent from Building A to Chapter 33: The Congested Network Building B. In this case, the only ways to prevent these packets from being dropped is to install a faster link between the buildings or stop sending SO much data. What we can use QoS to do is determine more specifically which packets should and should not be dropped. (See Chapters 31 and 32 for more information on designing a QoS scheme.) Let's clear those counters now, SO that the next time we look we'll have some fresh data: Bldg-A-Rtr#clear counters so/o Clear "show interface" counters on this interfa