Interface Errors and Discards Explained: What the Counters Really Mean

"The link is up, but users say it's slow." Some of the most common network complaints come from interfaces that look healthy on a status map but are quietly dropping or corrupting traffic. The evidence is almost always in the interface counters. You just need to know what they mean.

This guide explains the counters that matter, what usually causes them and how to monitor them properly.

Where the counters come from

Most monitoring tools read interface statistics from the standard IF-MIB (RFC 2863) via SNMP, or from equivalent YANG paths through streaming telemetry. The key objects are:

Vendor CLIs break these down further (CRC, runts, giants, overruns and so on), but the SNMP view above is what most dashboards use.

Errors vs discards: the key distinction

• Errors mean something is physically or electrically wrong: the packet arrived damaged or couldn't be transmitted. The usual suspects are cabling, optics, ports or duplex settings.
• Discards mean the packet was fine, but the device chose to drop it. It ran out of buffer, a queue was full, or a policy dropped it. The usual suspects are congestion and QoS configuration.

Getting this distinction right points troubleshooting in the correct direction immediately: physical layer vs. capacity and configuration.

Input errors and CRC

CRC errors (frame check sequence failures) are the most common input error. The receiving port calculated a checksum that didn't match, so the frame was corrupted in transit.

Common causes: - Dirty or damaged fiber connectors, the number one cause in data centers - Failing or incompatible optics, or optics running outside their power range - Damaged copper cables or excessive cable length - Electrical interference on copper runs

Troubleshooting tip: check optical receive (Rx) power on both ends. Low Rx power combined with CRC errors almost always means cleaning or replacing the fiber or optic. Always clean connectors before replacing hardware; it is faster and fixes most cases.

Runts, giants and alignment errors point to duplex mismatches (on older copper links), MTU mismatches or faulty NICs.

Output errors

Output errors are less common on modern full-duplex links. When they appear, suspect: - A hardware fault on the transmitting port - Late collisions from a duplex mismatch on copper links - Driver or ASIC issues on the device, so check vendor bug notes

Discards and output drops

Output discards are the classic sign of congestion: more traffic was queued for the interface than it could send. Traffic may average 40% over five minutes and still overflow buffers during microbursts lasting milliseconds.

Common causes: - Speed mismatch, such as 25G servers sending into a 10G uplink, or many-to-one incast in storage or big-data traffic - Microbursts that polling at 5-minute intervals will never show - QoS policies dropping lower-priority classes by design - Shallow buffers on some switch platforms

Input discards usually mean the device couldn't process incoming packets fast enough (control-plane or buffer exhaustion) or packets hit a drop policy, such as an unknown VLAN or protocol.

Troubleshooting tip: if discards grow while average utilization looks moderate, you are almost certainly seeing microbursts. High-resolution streaming telemetry or per-queue counters will confirm it. The fix may be QoS tuning, buffer configuration or more uplink capacity.

32-bit vs 64-bit counters

The original ifInOctets and ifOutOctets are 32-bit counters. They wrap at about 4.29 billion (2³²). At 1 Gbps line rate a 32-bit octet counter wraps in about 34 seconds, so a 5-minute poll could miss several wraps and report nonsense.

Always use the 64-bit high-capacity counters (ifHCInOctets, ifHCOutOctets, ifHCInUcastPkts and so on) for any interface faster than about 100 Mbps. They require SNMPv2c or SNMPv3; SNMPv1 doesn't support 64-bit counters.

Monitor rates and ratios, not raw counters

Raw counter values are meaningless on their own. A port with 50,000 CRC errors might have logged them all two years ago. What matters is the rate:

• Errors per second or errors per polling interval
• Error ratio: errors ÷ total packets. A ratio above roughly 0.01% (1 in 10,000 packets) deserves investigation on most links, and any sustained CRC errors on a data-center fiber link are worth a look.

In PromQL, an error rate looks like this:

rate(ifInErrors{instance="$device", ifName="$interface"}[5m])

Handle counter resets. Counters reset when a device reboots or an interface is cleared. Good tools detect resets (a counter going down) and don't calculate negative or huge rates. SNMP's ifCounterDiscontinuityTime helps identify them.

Sensible alerting

• Alert on sustained error rates, for example non-zero CRC errors across three consecutive polls, not a single sample.
• Use different thresholds for errors and discards. Any sustained errors on a fiber link are worth a ticket. Discards need context, because some QoS drops are intentional.
• Combine with optical levels: rising errors plus falling Rx power is a high-confidence physical-layer alert.
• Route physical-layer alerts to the team that handles cabling and optics, and discard and congestion alerts to capacity or network engineering.

A quick troubleshooting checklist

1. Are the counters incrementing now, or historical? Clear them (with approval) or compare two readings.
2. Errors or discards? Physical vs congestion.
3. For errors: check optical power on both ends, clean connectors, swap optics, then the cable, then the port.
4. For discards: check utilization at high resolution, queue statistics and QoS policy.
5. Check the other end of the link. Input errors on one side often mean a transmit problem on the other.

Key takeaways

• Errors mean physical problems. Discards mean congestion or policy.
• Always use 64-bit counters on fast links.
• Monitor rates and ratios, not raw totals, and handle counter resets.
• Moderate average utilization with rising discards usually means microbursts.
• Clean fiber before replacing hardware.