packet drop on 10gb/s interface

Question

I have a certain number of packets dropped on my 10gb/s interface, on Cisco 6500 with Sup 720. You can see underneath the number of dropped packet within a minute, after I cleared the counters.

We don't see any performance degradation, and none of our customers complained. Is this going to be a serious problem in future? I've never seen a single packet in the queue. I'm considering changing the input queue size to 1024 because it is 75 packet in the queue by default, but I'm wondering why packets don't enter in the queue at all before being dropped. On 1gb/s interfaces I don't see any dropped packets at all and everything is fine. Please help me resolve the problem with queue drops.

sh int TenGigabitEthernet1/1

 Hardware is C6k 10000Mb 802.3, address is 000f.3589.ac00 (bia 000f.3589.ac00)
  Description: transit 
  Internet address is 192.0.2.1/24
  MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 84/255, rxload 3/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 10Gb/s
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:00:40
  Input queue: 0/75/8097/0 (size/max/drops/flushes); Total output drops: 0  <-----
                    ^^^^
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 138646000 bits/sec, 99380 packets/sec
  5 minute output rate 3321988000 bits/sec, 329345 packets/sec
  L2 Switched: ucast: 158 pkt, 51401 bytes - mcast: 0 pkt, 0 bytes
  L3 in Switched: ucast: 4120795 pkt, 695621509 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 13774697 pkt, 17424995312 bytes mcast: 0 pkt, 0 bytes
     3484933 packets input, 608041136 bytes, 0 no buffer
     Received 0 broadcasts (0 IP multicasts)
     0 runts, 40 giants, 0 throttles
     8097 input errors, 7120 CRC, 894 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     11742838 packets output, 14837984934 bytes, 0 underruns
     0 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

Answer 1

I'm wondering why packets don't enter in the queue at all before being dropped.

Because they were errors: 8097 input errors, 7120 CRC, 894 frame It will not queue a packet that wasn't received properly -- or wasn't received completely (input queue is in software, you can still overrun the hardware queue, which you cannot change)

Answer 2

I see this in your output:

8097 input errors, 7120 CRC, 894 frame, 0 overrun, 0 ignored
^^^^               ^^^^      ^^^

This means you could have a faulty network interface card (NIC), cable, or driver.

Answer 3

CRC errors tend to indicate a problem with the signal as it crosses the medium between devices. Where 1G was often much more resilient to minor issues, 10G can be very particular about the medium.

For copper connections, this could indicate some sort of interference bleeding into the wire if you are not using shielded cable, or a problem with ground in shielded cables.

For fiber, I have come across errors a number of times, and the most common cause in my experience is that no one had or used a proper fiber kit to clean the fiber (transceivers, cables, and infrastructure) when making connections. This is true even with brand new cables (and sometimes more so).

A fiber scope can be very useful for this process, as it will allow you to verify that the surfaces are clean and free of any defect (scratches, etc) prior to making the connection.

As has been indicated in other answers and comments, check that your Rx signal is well within acceptable margins (not too strong or too weak) if your hardware supports it. If nothing else suggested fixes it, then look at swapping out the transceivers and cables if possible (remember to clean again if you do so).