[c-nsp] Troubleshooting uncategorized output drops and errors on the 6500

[John Neiberger]

Possibly, but I don't think so. There are no output queue drops.
However, I just checked and I see the following:

23.                         InDiscards = 1174
24.                        OutDiscards = 270028974
25.                           InErrors = 0
26.                          OutErrors = 135014487
27.                    InUnknownProtos = 0
28.                              txCRC = 67507244

Those txCRC errors look like A Bad Thing (tm).

TxCRC—This increments when frames are transmitted with a bad CRC, but
it does not include frames aborted due to a late collision. This
counter typically increments on an egress port when a frame is
transmitted that is received as an ISL frame on an ingress port, but
that carries an Ethernet packet with a bad CRC inside it, while the
ISL packet itself has a good CRC. It can also be caused by bad switch
hardware. A way to troubleshoot this is to send broadcast traffic on a
port and see if the counter increments on all egress connected ports.
If this happens independent of the port where you send traffic into,
there is a failure in the switch hardware, most probably the chassis
or supervisory module. If the counter is incrementing only when a
certain module is used to send traffic into, this module has a
hardware failure. If the counter is only incrementing on a few ports,
the ports themselves have a problem. If the cause cannot be determined
by the previous test, check the neighbor switches that are ISL
connected, or check ISL connected end-devices. Contact Cisco Technical
Support if you need further assistance.



On Thu, Jul 26, 2012 at 2:58 PM, Richard Clayton <sledge121 at gmail.com> wrote:
> John
>
> Could your drops be due to microburst
>
> On 26 July 2012 18:37, John Neiberger <jneiberger at gmail.com> wrote:
>>
>> I've got another strange issue brewing. We have a 1-gig interface on a
>> 6500 (6748 blade) that has a high number of output errors and output
>> drops. The drops are not queue drops. Here are the stats, one week
>> after clearing the counters.
>>
>> Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops:
>> 1158860
>>   Queueing strategy: fifo
>>   Output queue: 0/40 (size/max)
>>   30 second input rate 854000 bits/sec, 101 packets/sec
>>   30 second output rate 78000 bits/sec, 116 packets/sec
>>      97152626 packets input, 115649666904 bytes, 0 no buffer
>>      Received 0 broadcasts (0 multicasts)
>>      0 runts, 0 giants, 0 throttles
>>      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>>      0 watchdog, 0 multicast, 0 pause input
>>      0 input packets with dribble condition detected
>>      90216394 packets output, 7441734020 bytes, 0 underruns
>>      579430 output errors, 0 collisions, 0 interface resets
>>      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
>>
>>
>> Packets dropped on Transmit:
>>
>>     queue     dropped  [cos-map]
>>     ---------------------------------------------
>>     1                        0  [0 1 ]
>>     2                        0  [2 3 4 ]
>>     3                        0  [6 7 ]
>>     4                        0  [5 ]
>>
>> I haven't been able to figure out what could be causing such a high
>> rate of errors and drops. I have a TAC case open, but the engineer
>> hasn't been able to explain what we're seeing. I'm probably just going
>> to coordinate with the server and app owners to move this to another
>> link, but I'm still very curious about what could cause this behavior.
>>
>> Any ideas?
>>
>> Thanks,
>> John
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>