[c-nsp] Troubleshooting uncategorized output drops and errors on the 6500
sledge121 at gmail.com
sledge121 at gmail.com
Thu Jul 26 18:19:19 EDT 2012
I would say you possibly have two issues, txCRC and microburst, the latter only being a problem if it is having a noticeable affect on applications.
On 26 Jul 2012, at 22:03, John Neiberger <jneiberger at gmail.com> wrote:
> 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/
>>
>>
More information about the cisco-nsp
mailing list