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