I have found a few places that discuss this issue:
GigabitEthernet0/1 is up, line protocol is up
Hardware is MV96340 Ethernet, address is 0024.979c.29a1 (bia 0024.979c.29a1)
Description: 20Mbps to AT&T AVPN MPLS service AT&T Ethernet ckt id - MMEC978774 ATI
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 2/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is T
output flow-control is XON, input flow-control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 3w3d
Input queue: 0/75/2064/0 (size/max/drops/flushes); Total output drops: 797714
Queueing strategy: Class-based queueing
Output queue: 0/1000/0 (size/max total/drops)
30 second input rate 961000 bits/sec, 298 packets/sec
30 second output rate 577000 bits/sec, 310 packets/sec
701104295 packets input, 118218661 bytes, 0 no buffer
Received 1060158 broadcasts, 0 runts, 0 giants, 1488 throttles
39351 input errors, 0 CRC, 0 frame, 0 overrun, 39351 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
678681373 packets output, 24190243 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 13 pause output
0 output buffer failures, 0 output buffers swapped out
Each reference I have seen discusses this could be a buffer issue.
Any ideas on how to track that down? I am not coming up with anything viable when searching.
Here is the interface config:
description 20Mbps MPLS
no ip address
ip flow ingress
ip pim sparse-dense-mode
no cdp enable
One thing that quickly jumps out to me is the load-interval. Could this be a possible cause?
This is a 2851 - running sp services IOS
The 'input errors' counter is simply the sum of the various errors that can be seen with inbound traffic (CRC, frame, overrun, and ignored). For that reason, you will generally find that the input errors is identical to another counter or matches up with the sum of the 4 categories mentioned. This is expected behavior. Ignored errors themselves are generally the result of bursty traffic that is hitting this interface inbound. Within each interface, we have a set limit of buffers to accommodate inbound packets called an Rx ring. If we experience a microburst of traffic on the interface at a rate faster than the interface can keep up with or clean out, we will increment the ignored or overrun counter depending on where the packet is within the input cycle. This indicates that this packet was dropped. The general solution is to look at the other side of the link and make sure flow-control is enabled and that it is able to accept pause frames if applicable. The interface should send these out if supported to tell the other side to slow down. Outside of that, you could look at implementing QoS on the opposite end of the link to limit bursts but the side-effect of this could be a bottleneck. The general recommendation is to identify the source of the bursts through a packet sniffer and determine a) is this legitimate traffic and if not, eliminate it and b) if the traffic is legitimate and is continuing to cause problems, offload it to another device more capable of handling higher traffic rates.
Given that the total number of input errors is a very small percentage of your total packets input, though, I don't suspect that these are incrementing very often. There are also some hardware counters, depending on the driver, that may provide further confirmation of the inbound hardware limitation being reached that can be checked in 'show controllers'. Hope this helps.