Dropping Packets on a 2621XM

The first output shows a cosmetic error - the "Total output drops" count is 50748, the drop count under "Output queue" is 507481, but that's probably not relevant. Since you have a T1 which is presumably being fed by a 10M or 100M ethernet drops are to be expected. Either you have bursty traffic or you have TCP flows which are adapting to the available bandwidth by increasing their rate until packets are dropped. Drops in that situation are (usually) normal. What systems/services do you have on either side of this router?

Sam

Just to expand slightly.

Drops are more than just "normal" - TCP is specifically designed to cause drops. Wherever you have end stations on faster links than an intermediate link you can expect TCP to create drops.

Worry if there are no drops.

The idea is that TCP probes the network to determine it's capacity and it does this by filling it up until it overflows (i.e. causes drops) . TCP then backs off and immediately starts probing again. TCP therefore constantly causes drops in the network design discussed. Thre can of course be factors that prevent TCP from generating enough traffic in which case there will not be drops.

By adding buffers you may well be degreasing the preformance of your network when TCP is driving the network to capacity. The buffers do nothing more than add delay to the packets since they just have to wait in a longer queue.

Make sure TCP selective Ack is turned on, it is in most modern IP stacks, and stop worrying:-) Oh and probably get rid of those buffers.

Turning off weighted fair queuing is probably a bad idea. Just put it all back.

Drops are good.

Indeed, but we don't know whether the OP's traffic is TCP at all - it might be all VOIP for instance - so I didn't want to assume.

Again if we'd had a bit more background I'd have said the same thing - the advice from Cisco seemed the opposite of what I would have expected. On the other hand if the traffic is known to be, say, some bursty UDP-based protocol then increasing the size of the buffer to accommodate bursts and eliminate retries would be a good thing. We also don't know the topology of the rest of the network.

Usually, in this kind of situation. :-)

Sam

It is an edge router. ISP on serial, my network on ethernet.

Thanks.

so if you want to get a better understanding of what is going on - you might want to set up a monitoring tool (PRTG trial version or similiar ilk) and poll the router via SNMP and take a look at the correlation between link utilization and output drops

OK, so what is connected on the ethernet and what kind of traffic does it source and sink? Do you host a server or servers on your ethernet? Are there desktop clients (or the equivalent) there? Is the traffic web browsing (in which direction?), or file serving/sharing (peer to peer or otherwise), or Skype/VOIP or other multimedia stuff, or something else completely? If you don't know that, or if it's not immediately obvious to you, then like Merv I suggest you set up some kind of monitoring - MRTG/PRTG or the like - and see if the drops correspond to levels of traffic (though if it's very bursty UDP you might not be able to tell easily). It's notable that balance of traffic counts in the two sets of stats you originally gave are not the same which suggests that traffic isn't simply between providers of traffic on one side of the link and consumers on the other.

There are also things you may be able to do on the router to reveal the traffic flows but I'm not sure what to suggest - I haven't done this kind of thing on a router for a long time and never on a 2600 series, so I'd think of ip accounting or netflow, but they may not be appropriate here.

Sam

additionally

configure "load-interval 30" on all interfaces so that you can see a more "instantanious view of traffic on each of the interface - 5 minute averages are generally not useful.

Also post the output of "show ip traffic" to see if anything of interest is revealed.

I think in later versions of IOS you can issue a clear ip traffic command - perhaps 12.3 or 12. 4 - so try that - it is easier than power cycling the router ;-)) or calculating diffs for the various counters displayed in the output of show ip traffic