e 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 percent of all the packets. So, why do we have a problem? OK, I'll admit it, I led you down the wrong path, but I did it to give you some real- world experience. Let's think for a moment here. These numbers look good to me. Sure, we're saturated, but we're not dropping all that many packets, are we? Why, then, are we getting complaints? The answer is a deceptively simple one: we're looking at the wrong side of the link. Take another look at lines 16 and 17: minute input rate 1509000 bits/sec, 258 packets/sec minute output rate 259000 bits/sec, 241 packets/sec The input is almost maxed, not the output! When we drop packets due to conges- tion, we drop them on the outbound journey. Remember the funnel example from Chapter 29? We're looking at the bottom of the hose here. The only packets that can come out of it are the ones that made it through the funnel! We'll never see the ones that were dropped on the other side. Determining Whether the Network Is Congested So, let's take a look at the other side of the link with the same show interface command: Bldg-A-Rtr# sho int so/o Serialo/o is up, line protocol is up Hardware is PowerQUICC Serial Description: T1 WAN Link --] Internet address is 10.10.10.1/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 