Interface - Input Errors and Ignored same

[Rick Morris]

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:

interface GigabitEthernet0/1
description 20Mbps MPLS
no ip address
ip flow ingress
ip pim sparse-dense-mode
load-interval 30
duplex full
speed 100
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

Thanks,

Rick Morris

[Brandon Lynch]

Hey Rick,

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.

Brandon

[kevynjnr]

That's is a very insightful explanation Brandon.

Thank you,

Joe