---
type: Article
title: "SNMP Interface Errors"
description: "A link can be up and quietly failing. SNMP interface errors and discards expose it — the ifTable columns to read, and why to alert on rate, not totals."
resource: "https://snmp-monitoring.com/sensors/network/interface-errors/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Diagram of an external SNMP poller reading ifInErrors, ifOutErrors, ifInDiscards and ifOutDiscards from an interface's ifTable to monitor packet errors](https://snmp-monitoring.com/img/sensors/interface-errors-poll.webp)

## 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.

| Counter | OID | What it counts |
|---|---|---|
| `ifTable` (parent) | `1.3.6.1.2.1.2.2.1` | Interface table, one row per `ifIndex` |
| `ifInErrors` | `1.3.6.1.2.1.2.2.1.14` | Inbound packets with errors (corrupt / malformed) |
| `ifOutErrors` | `1.3.6.1.2.1.2.2.1.20` | Outbound packets that couldn't be transmitted |
| `ifInDiscards` | `1.3.6.1.2.1.2.2.1.13` | Good inbound packets dropped (no error, e.g. buffer full) |
| `ifOutDiscards` | `1.3.6.1.2.1.2.2.1.19` | Good outbound packets dropped (queue/congestion) |

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](/setup/snmpd-conf.md).

1. **Walk inbound errors** across every interface:
   ```bash
   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):
   ```bash
   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:
   ```bash
   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](/monitoring/double-durability.md): 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](https://ostr.io/service/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.

![Chart of SNMP interface error rate per second over 24 hours showing a rising ifInErrors trend crossing an alert threshold](https://snmp-monitoring.com/img/sensors/interface-errors-chart.webp)


## FAQ

**What's the difference between an interface error and a discard?**
An error (`ifInErrors` / `ifOutErrors`) is a packet that was malformed or corrupt — a physical-layer problem like a bad cable or transceiver. A discard (`ifInDiscards` / `ifOutDiscards`) is a perfectly good packet the interface dropped anyway, usually because a buffer or queue was full — a congestion problem. They point at different fixes.

**Why is my `ifInErrors` count huge but nobody's complaining?**
It's a lifetime counter, so a large absolute number can just be years of accumulation. What matters is the rate: read it twice and check whether the delta is climbing. A flat counter, however large, is a healthy link.

**Can these counters wrap around?**
Yes. They're `Counter32`, so they roll back to zero after about 4.29 billion. If a delta comes out negative, the counter wrapped or the interface reset — discard that sample instead of trusting it.

**Which SNMP version should I use to read error counters?**
SNMPv2c is fine for read-only polling on a trusted network and is the common choice. Use SNMPv3 when you need authentication and encryption on the wire.

## Conclusion

SNMP interface errors live as four counters in the `ifTable` at `1.3.6.1.2.1.2.2.1` — `ifInErrors` (`.14`), `ifOutErrors` (`.20`), `ifInDiscards` (`.13`), and `ifOutDiscards` (`.19`) — and the trick to using them is to watch the *rate*, not the lifetime total. Errors point at the physical link; discards point at congestion; a flat counter means all is well. To monitor packet errors properly, publish these columns in your [snmpd.conf](/setup/snmpd-conf.md), confirm they clear your [OID allowlist](/setup/oid-allowlist.md), and see the rest of the [sensor & OID catalog](/sensors/index.md) or the [full OID list](/sensors/all.md). Reading them from outside is what turns a slow-motion cable failure into an early alert instead of an outage.