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: Determining Whether the Network Is Congested 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 indicates to me that there was probably a problem in the past that led someone to pull 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 established 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 the queueing strategy is FIFO (first in, first out). Links 2 Mbps and below should be using weighted fair queuing (WFQ), SO there's something to investigate. Looking further, you'll see that there have been 548,941 drops on the output queue and 3,717 drops on the input queue. This means that since the last time the counters were cleared (now you know why we didn't clear them), we've dropped 548,941 packets while transmitting. Line 13 shows how long it's been since the counters were cleared: Last clearing of "show interface" counters 3w4d Line 22 shows how many packets we've sent: 282883104 packets output, 3613739796 bytes, 0 underruns So, in three weeks and four days, we've transmitted 282,883,104 packets and dropped 548,941. Some simple math shows that this is only 1/10th of one 