me completely saturated in one direction. This coincides nicely with what we're seeing on the router. 1600.0 k 1200.0 k 800.0 k 400.0 k 0.0 k Figure 31-2. MRTG graph showing T1 utilization OK, SO the link is saturated. So what? We're getting our money's worth, right? If that's the case, why are users complaining of slowdowns? Let's look deeper. The first thing you should always look for is problems at the physical layer. Look for errors in the show interface output. The bold lines toward the bottom of the output do indeed indicate some errors: 819 input errors, 559 CRC, 227 frame, 0 overrun, 0 ignored, 33 abort 0 output errors, 0 collisions, 1 interface resets These two lines show input errors, CRC errors, framing errors, abort errors, and an interface reset. Hmm. Not SO good. Let's not get excited just yet, though. The first thing you should do when you see errors-especially when they're relatively small in number, as in this case-is to wait a few minutes, and do a show interface again. Here are the relevant results after executing the same command 10 minutes later: Chapter 31: The Congested Network 819 input errors, 559 CRC, 227 frame, 0 overrun, 0 ignored, 33 abort 0 output errors, 0 collisions, 1 interface resets As you can see, they're identical; none of the counters are incrementing. This indi- cates to me that there was probably a problem in the past where someone pulled out the T1 cable and quickly reset it. Or, it could be that the telecom provider had a blip on the line. Either way, it's not worth worrying about right now. Once we've estab- lished that the counters are not incrementing, we should clear them SO we don't waste time chasing ghosts the next time we're in the router. We don't want to do that yet, though-we still need the data. The next thing we need to look at is the health of the input and output queues. The previous show interface output includes the following: Queueing strategy: fifo Output queue 0/40, 548941 drops; input queue 0/75, 3717 drops The first thing you should notice is that th