What causes total output drops on a cisco switch interface?

  • I have an HP c7000 blade chassis which contains Cisco 3120X and Cisco 3120G switches running ios 12.2(58)SE1. The blades themselves are very lightly loaded yet many interfaces on different blade switches in the chassis show a fairly high number of output drops. If I check the number of output drops repeatedly I not only see the counter increasing but sometimes it decreases. The numbers don't correlate with the packets/s recorded on the interface. QoS settings are default for the platform.

    The following samples were all taken within a 30 second period:

    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2255550
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2255550
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2255550
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2255550
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2255550
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 2255550
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 451110
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 451110
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 902220
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1353330
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1804440
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1804440
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 1804440
    bc1019-3120-stack>sh int gi2/0/7 | i output drops
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 451490
    
    bc1019-3120-stack>sh int gi2/0/7 | i output rate
      5 minute output rate 301000 bits/sec, 119 packets/sec
    

    1) Is there anything else that can cause output drops besides the server nic not receiving the frames quickly enough?

    2) What is the maximum number of output drops the interface counter can record? Does it rollover when it reaches the max?

    3) What would be considered a healthy rate of output drops?

    As Leonardo Abdalla pointed out, the erratic output drops seen on our blade chassis are a result of bug CSCtq86186

    It's a bug. We hit the same thing, upgraded to c3750e-universalk9-mz.150-2.SE4.bin and all is well. JB

  • Aaron

    Aaron Correct answer

    9 years ago

    Unless someone is clearing counters you should never see any odometer-type counters (those that increment based on a packet action) decrease, they should always increase. That part sounds like a bug.

    As far as what causes output drops in particular, there are so many different causes that it's very difficult to pinpoint it exactly. Sometimes there is congestion inside the switch's backplane and those might show up as output drops on the outgoing interface. In rare circumstances you can also get microbursts that don't show up when polled at 1 minute intervals that quickly overload the interface, but then drop back down very quickly. I would suggest grabbing the SNMP OID for output drops and then graphing that and see how it corresponds to the CLI counter.

    Generally speaking, you don't want any output drops as they indicate a packet that did not make it to its destination. But, if you're running your links hot (which you say you're not) they're unavoidable to an extent, mostly due to interior switch buffering, etc.

    I'm wondering if there's so many drop outs in this case, the counters wrap around.

    They are 32bit counters, so you're getting nowhere near the limits. (and possibly 64bit internally)

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM