drop rate on a fast ethernet interface with low load

[joepena2012]

                   Hi gentlemen,

i have a CPE Router between provider and me.

On this CPE Routers WAN Interface i have a high rate of output drops, even if the load is low.

Is there a whitepaper available how to understand (output)-drops on interfaces?

thanks in advance

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

the interface output shows me the following:

FastEthernet0/0 is up, line protocol is up
  Hardware is MV96340 Ethernet, address is 0019.2f2a.0108 (bia 0019.2f2a.0108)
  Description: SG_DC to MPLS Provider Edge
  Internet address is X.X.X.X/30
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 2/255, rxload 2/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 03:14:38
  Input queue: 0/2048/0/0 (size/max/drops/flushes); Total output drops: 62368
  Queueing strategy: Class-based queueing
  Output queue: 0/2048/0 (size/max total/drops)
  5 minute input rate 1012000 bits/sec, 416 packets/sec
  5 minute output rate 1070000 bits/sec, 432 packets/sec
     5506836 packets input, 1400591389 bytes
     Received 10 broadcasts, 0 runts, 0 giants, 0 throttles
     22 input errors, 0 CRC, 0 frame, 0 overrun, 22 ignored
     0 watchdog
     0 input packets with dribble condition detected
     5879636 packets output, 1697453086 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

interface FastEthernet0/0
description SG_DC to MPLS Provider Edge
ip address x.x.x.x 255.255.255.252
no ip redirects
no ip proxy-arp
tx-ring-limit 512
tx-queue-limit 512
duplex full
speed 100
no cdp enable
hold-queue 2048 in
hold-queue 2048 out

[paolo bevilacqua]

You cannot judge that the "output is low" looking at 5 minutes statistics (and not even at 30 secs).

There are burst of traffic that exceed circuit capacity, and these packets are dropped.

Since you have already increased the output queue, you can only try to find what is generating the bursts, and why.

Other than that there is nothing you can do.

[Joseph W. Doherty · Accepted solution]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

As Paolo correctly describes, there's much that can happen in 5 minute or 30 seconds (or even 1 second).

Not 100% sure, but output drops might count drops for reasons beyond queue-drops, i.e. increasing just your queue-depth and tx-ring-limits might not help at all.

Additionally,  for TCP, counter intuitively, in some situations, excessive queuing can  make matters worst, even without considering additional latency.

You shouldn't need to make your (total) queue buffers larger than the 1/2 BDP (bandwidth delay product).

You might be much better served by reducing your queue buffers and activate WRED, FRED and/or FQ.

PS:

BTW, your total drops appear to be less than 1% of your output count.  This isn't really excessively high, although it might be improved.