Total Output Drops on Port-Channel

[Grayson Wells]

What are the reasons why a port-channel interface would experience output drops? There doesn't appear to be any saturation whatsoever. I have to 1 Gbps trunks etherchanneled and my network monitoring tells me that there isn't an overly large amount of traffic being pushed through the link. Below is the output of the show interface where it shows the output drops. The links are multimode fiber (1000BaseSX SFP).

Port-channel22 is up, line protocol is up (connected)

  Hardware is EtherChannel, address is 6c20.5670.9084 (bia 6c20.5670.9084)

  Description: sfidfsw22.sys

  MTU 1500 bytes, BW 2000000 Kbit/sec, DLY 10 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, link type is auto, media type is unknown

  input flow-control is off, output flow-control is unsupported

  Members in this channel: Gi3/0/4 Gi4/0/4

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 00:06:33, output 00:00:00, output hang never

  Last clearing of "show interface" counters 1w1d

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3135

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 634000 bits/sec, 348 packets/sec

  5 minute output rate 4389000 bits/sec, 504 packets/sec

     173750638 packets input, 33900478767 bytes, 0 no buffer

     Received 838679 broadcasts (113009 multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 113009 multicast, 0 pause input

     0 input packets with dribble condition detected

     257080310 packets output, 264399516201 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 pause output

     0 output buffer failures, 0 output buffers swapped out

[Grayson Wells]

It should also be noted that this is a link between an access switch and a distribution switch. The distribution switch shows about 250k drops per day, while the access switch side of the link shows no drops at all.

[Joseph W. Doherty]

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

What are the reasons why a port-channel interface would experience output drops?

Usually the same reasons as most interfaces, i.e. frames/packets arrive faster than they can be transmitted, excess frames/packets are queued until queue(s) fill(s); frames/packets then get dropped.

It's not unusual for typical network monitoring bandwidth utilization to not reveal this problem, as the congestion is often transient and can happen in very short time intervals.  (One term for this is microburst.)

When working with port-channels, you might want to review your hashing algorithm choice.  It's possible a different hashing distribution may decrease your drop rate.

[Daniel McDavid]

Can you post the configuration for po22, gi3/0/4, gi4/0/4 and the corresponding ports on the other side of the link?