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 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 4 and 5: 5 minute input rate 1509000 bits/sec, 258 packets/sec 5 minute output rate 259000 bits/sec, 241 packets/sec The input is almost maxed, not the output! When we drop packets due to congestion, we drop them on the outbound journey. Remember the funnel example from Chap- ter 31? 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 from this point of view. Chapter 33: The Congested Network 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 usec, reliability 255/255, txload 250/255, rxload 47/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) LCP Open Open: IPCP, CDPCP Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 3w4d Input queue: 0/75/0 (size/max/drops); Total output drops: 152195125 Queueing strategy: weighted fair Output queue: 63/1000/64/152195113 (size/max total/threshold/drops) Conversations 7/223/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 261000 bits/sec, 238 packets/sec 5 minute output rate 1511000 bits/sec, 249 packets/sec 282883104 packets input, 3613739796 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 872 input errors, 472 CRC, 357 frame, 0 o