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 <[email protected]> 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 <[email protected]> wrote: >> John >> >> Could your drops be due to microburst >> >> On 26 July 2012 18:37, John Neiberger <[email protected]> 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 [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
