How to Monitor Interface Errors & Discards via SNMP

By the SNMP Monitoring team · Reviewed July 2026

Traffic graphs tell you a link is busy. Error counters tell you a link is sick — and they usually start climbing hours or days before anyone opens a ticket about "the network being slow." A frayed patch cable, a duplex mismatch, an SFP going marginal, a switch buffer that keeps filling: all of it shows up first as errors and discards ticking upward on an interface. Learn to watch these two counters as a rate and you'll catch a class of problems while they're still annoyances instead of outages.

This is the how-to — diagnosing faults. The full IF-MIB object reference is the twin page interface OIDs. Parent: network monitoring.

Errors versus discards

People smash these together and shouldn't. They mean different things and point at different faults:

• Errors are packets the interface received or sent that were malformed — failed CRC, wrong frame length, alignment problems. The frame arrived corrupt. That's almost always physical: a bad cable, a dirty fiber connector, EMI, a dying transceiver, or a duplex mismatch mangling frames.
• Discards are packets that were perfectly valid but got dropped anyway — most often because a buffer or queue was full. Nothing is wrong with the packet; the device just had nowhere to put it. That points at congestion, undersized queues, or a policer, not a cable.

So an interface with rising errors sends you to the physical layer with a light meter and a spare cable. Rising discards sends you to look at load, QoS and queue depth. Same table, opposite root causes — which is exactly why you monitor them as separate signals.

The OIDs to watch

All four live in the classic ifTable, one column each, indexed by ifIndex:

Every one of these is a cumulative Counter32. That word matters: the number only ever goes up, and the absolute value is close to useless. A switch that's been up for a year might show 40,000 lifetime errors and be perfectly healthy. What you care about is whether the counter is moving now.

Rate, not total

This is the rule that separates a useful error alert from a useless one:

1. Read the error counter and, alongside it, the matching packet counter (ifInUcastPkts and friends) at time T1.
2. Read both again at T2.
3. Errors in the window = Δerrors. Packets in the window = Δpackets.
4. Error ratio = Δerrors ÷ Δpackets. Or just track Δerrors ÷ Δseconds for an errors-per-second rate.
5. Alert when that rate or ratio crosses a threshold — not when the lifetime total is "big."

Why bother dividing by packets instead of just counting errors per second? Because 50 errors on a link forwarding two billion frames is background noise, while 50 errors out of 5,000 frames is a link that's on fire. The ratio normalizes for how busy the interface is. A common starting point: warn somewhere around a sustained 0.1% error ratio and investigate anything climbing steadily, but tune it to your gear — some media are noisier than others.

Reading them with snmpwalk

Pull the error columns straight off the device:

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.2.2.1.14

IF-MIB::ifInErrors.1 = Counter32: 0
IF-MIB::ifInErrors.2 = Counter32: 18342
IF-MIB::ifInErrors.3 = Counter32: 5
IF-MIB::ifInErrors.4 = Counter32: 0

Index .2 is the interesting one — 18,342 inbound errors while its neighbours sit near zero. That's the port to walk over to. Check discards on the same index too:

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.2.2.1.13

Then poll .2 again a minute later. If ifInErrors.2 jumped by a few hundred in that minute, it's actively bad, not a historical scar. Map the index to a name with ifName (1.3.6.1.2.1.31.1.1.1.1) so you know which physical port to chase. <RO_string> is a placeholder — keep real community strings out of docs and scripts you commit.

Common root causes

When the rate is real, the usual suspects, roughly in order of how often I've found them:

• Duplex mismatch — one side full-duplex, the other half. Classic on hard-coded legacy links. Shows as late collisions and a steady error trickle that gets worse under load. Fix the speed/duplex config to match on both ends.
• Bad cable or connector — kinked copper, a cable run past its length, a dirty or scratched fiber endface. Errors often rise when the cable is disturbed. Swap it and watch the rate.
• Marginal SFP/transceiver — optics degrade; light levels drift out of spec. Check DOM/digital-diagnostics if the platform exposes them.
• Congestion — this one shows as discards, not errors. The queue overflowed. The answer is capacity, QoS shaping, or offloading traffic, not a new cable.
• EMI / bad grounding — copper runs near noisy equipment. Rare, but it happens in industrial spaces.

Triage move: errors → physical layer; discards → capacity and queueing. Getting that split right saves you from re-seating cables on a congestion problem. For speed/duplex specifics see port speed; deeper diagnosis in troubleshooting.

Reference

This is the diagnostic how-to. For the complete object list, counter types and status enumerations, use the reference twin: interface OIDs. Related: interface traffic. Definitions at glossary; full index at all sensors.

Frequently asked questions

What OID shows interface errors in SNMP?

Inbound errors are ifInErrors (1.3.6.1.2.1.2.2.1.14) and outbound are ifOutErrors (1.3.6.1.2.1.2.2.1.20). For dropped-but-valid packets use ifInDiscards (.13) and ifOutDiscards (.19). All are cumulative Counter32 objects.

What's the difference between errors and discards?

Errors are malformed packets — failed CRC, bad framing — which point at a physical problem like a cable, connector or duplex mismatch. Discards are valid packets dropped because a buffer or queue was full, which points at congestion or undersized queues. Different counters, different fixes.

What causes interface errors?

Most commonly a duplex mismatch, a bad or overlong cable, a dirty fiber connector, or a failing transceiver. EMI and grounding issues are rarer. Because these are physical-layer faults, you chase them with cable swaps and optics checks, not config tweaks — unless it's a duplex mismatch, which is a config fix on both ends.

Should I alert on total errors or the error rate?

The rate. Lifetime totals only grow and say nothing about now — a year-old switch will show thousands of harmless historical errors. Alert on the change per interval, ideally as a ratio of errors to packets, so a busy link and an idle one are judged fairly.

Key takeaways

• Errors = malformed (physical layer); discards = dropped-but-valid (congestion). Don't conflate them.
• OIDs: ifInErrors .14, ifOutErrors .20, ifInDiscards .13, ifOutDiscards .19.
• They're cumulative Counter32 — alert on the rate/ratio, never the absolute total.
• Errors send you to cables, optics and duplex; discards send you to capacity and queues.
• Map ifIndex to ifName so an alert names a real port.
• Types and full columns: interface OIDs; an off-box external check via external monitoring still pages you when the site itself drops.