SNMP Interface Errors

A link can be up, carrying traffic, and quietly failing — and SNMP interface errors are how you catch it before anyone files a ticket. Every interface keeps a tally of packets it couldn't handle cleanly: frames it received garbled, frames it had to throw away, frames it couldn't transmit. When that tally starts climbing, you've got a physical or capacity problem hiding behind an interface that otherwise looks healthy. This page covers what those error and discard counters mean, the exact ifTable columns that hold them, how to read them by hand, and how to alert on the rate of errors rather than a meaningless lifetime total.

What is Interface Errors and why monitor it

Interface errors are packets that didn't make it through cleanly. The interface counts them separately from good traffic, and there are two distinct categories worth keeping straight, because they point at very different faults.

Errors are packets that arrived or were sent malformed — a bad checksum, a CRC failure, a runt or giant frame, an alignment problem. These almost always mean a physical-layer fault: a marginal cable, a dying transceiver, electrical interference, a duplex mismatch. The wire itself is corrupting data.

Discards are different. These are packets the interface dropped even though nothing was wrong with them — usually because a buffer was full or a queue overflowed. Discards point at congestion or resource pressure, not broken hardware. The packet was fine; the interface just had nowhere to put it.

Why monitor packet errors at all? Because they're a leading indicator. Long before a flaky cable takes a link fully down, it starts corrupting a small fraction of frames — and every corrupted frame that carries TCP data forces a retransmit, which quietly inflates latency and throttles throughput. Users report "the network feels slow" while every up/down check says green. Rising ifErrors is often the only signal that explains it, which is exactly why interface error monitoring earns its place next to traffic and status. Catch the trend early and you replace a cable on your schedule instead of during an outage.

The OID: interface error counters in the ifTable

There's no single "interface errors" OID — the counters live as separate columns in the IF-MIB ifTable at 1.3.6.1.2.1.2.2.1 (RFC 2863), one set per interface, each keyed by ifIndex. Four columns carry the day-to-day signal. All are Counter32 values: cumulative, monotonically increasing totals since the interface last reset.

Here's the trap. These are lifetime counters, not gauges. A raw reading of ifInErrors = 4213 tells you almost nothing — 4,213 errors over three years is noise; 4,213 in the last hour is an emergency. The number only becomes meaningful when you read it twice and look at the delta: how fast is it climbing? A counter that's flat is a healthy link. A counter that's ticking up steadily is the one to chase. Being Counter32, these can also wrap back to zero after ~4.29 billion, so a delta that comes out negative means a wrap or a reset — discard that sample rather than trust it.

How to query it

Any Net-SNMP client reads these columns in seconds. The examples assume an SNMPv2c agent with a read-only community; if you haven't got that running, see the snmpd.conf guide.

1. Walk inbound errors across every interface:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.2.2.1.14
   

   Sample output:

   IF-MIB::ifInErrors.1 = Counter32: 0
   IF-MIB::ifInErrors.2 = Counter32: 152
   

2. Read errors and discards together for one interface (index 2):

   snmpget -v2c -c public 10.0.0.5 \
     1.3.6.1.2.1.2.2.1.14.2 1.3.6.1.2.1.2.2.1.20.2 \
     1.3.6.1.2.1.2.2.1.13.2 1.3.6.1.2.1.2.2.1.19.2
   

3. Force numeric output if the IF-MIB isn't installed locally:

   snmpwalk -v2c -c public -On 10.0.0.5 1.3.6.1.2.1.2.2.1.14
   

The useful figure is the rate. Poll the counter twice a known interval apart, subtract, and divide by the seconds elapsed to get errors per second. Better still, express it against total packets on the interface — an error ratio — so a busy link and a quiet one are judged on the same scale. A handful of errors per million packets is often just background; the same absolute count on a low-traffic link is a much louder alarm.

Normal vs alarming values & thresholds

There's no universal "bad" count, because it's the rate and ratio that matter, not the lifetime total. These bands work as a starting point:

• Flat counters (delta ≈ 0) — healthy. The link is passing frames cleanly; this is what you want to see.
• A tiny, stable error ratio — often background noise on some media; note the baseline and don't page on it.
• Steadily rising ifInErrors / ifOutErrors — a physical-layer fault developing: cable, transceiver, connector, or duplex mismatch. Investigate before it becomes an outage.
• Rising ifInDiscards / ifOutDiscards — congestion or buffer exhaustion, not broken hardware. The link may be undersized or a queue is overrunning.
• A sudden error burst that correlates with a config or hardware change — treat the change as the prime suspect.

Two rules keep error alerts trustworthy. First, alert on the delta or ratio over a window, never on the absolute counter — the lifetime total is almost always large and meaningless. Second, separate errors from discards in your alerting, because they send you to different places: errors mean check the physical link, discards mean check capacity and queues. Blur them together and you'll waste time swapping a perfectly good cable when the real problem was an overloaded uplink.

Alerting on this metric externally

Rising interface errors degrade the very network path your monitoring might depend on. As a link corrupts more frames, retransmits pile up, throughput sags, and an on-network alerter's own messages have to fight through the same failing link. In the worst case the errors climb until the link is effectively unusable — and the tool meant to warn you can no longer get a packet out.

Polling from outside removes that fragility. It's the principle behind double durability: an independent checker reads the error counters from beyond your network and computes the delta on its own hardware, so a degrading link still trips an alert even when it can barely pass traffic. SNMP being pull-based keeps it simple — the external side reads the ifTable error columns on its own schedule and doesn't need the ailing link to volunteer anything.

That's the shape of ostr.io Monitoring: agentless, zero-setup checks from outside your network with real-time email and SMS alerts, so a link quietly filling up with errors reaches you before it drags an application down with it.