SNMP Network Interface Monitoring — Bandwidth, Traffic & Errors

Network interface monitoring is the part of SNMP that just works. Unlike environmental readings, everything in this category lives in one standardized, portable tree — the IF-MIB (RFC 2863) — so the same OID means the same thing on a Linux server, a top-of-rack switch, or a core router. Poll it and you get throughput, utilization, error and discard counts, and link state for every interface on the box, without a single vendor MIB in sight. This page routes you to each interface metric and explains the one detail that trips everyone up: counters, not gauges.

Counters, not gauges

The thing to understand before anything else is that the IF-MIB reports traffic as monotonically increasing counters, not instantaneous rates. ifInOctets and ifOutOctets are running totals of bytes since the interface last reset. To get a bit-per-second rate you poll twice, subtract, and divide by the elapsed time. That's why every traffic page here talks about deltas rather than raw values.

There's a second, load-bearing detail: counter width. The original 32-bit octet counters (ifInOctets at 1.3.6.1.2.1.2.2.1.10) wrap — roll back to zero — surprisingly fast on modern links. A 32-bit byte counter rolls over in about 34 seconds at 1 Gbps and under 4 seconds at 10 Gbps, faster than most polling intervals, which makes the reading useless. The fix is the 64-bit high-capacity counters in ifXTable (ifHCInOctets at 1.3.6.1.2.1.31.1.1.1.6), which for practical purposes never wrap. On any interface faster than about 20 Mbps, use the 64-bit counters.

The interface metric pages

Each page below covers one facet of the IF-MIB with real OIDs, query commands, and rate-calculation examples:

  • SNMP Bandwidth Monitoring — turn octet counters into a utilization percentage against ifSpeed / ifHighSpeed, and alert on sustained saturation.
  • SNMP Interface Traffic — the raw in/out throughput read from ifHCInOctets and ifHCOutOctets, with delta calculation.
  • SNMP Interface ErrorsifInErrors (1.3.6.1.2.1.2.2.1.14), ifOutErrors, and discards, the early warning for a bad cable, duplex mismatch, or failing optic.
  • SNMP Interface Info — the descriptive side: ifDescr, ifType, ifSpeed, ifAlias, and ifOperStatus for mapping indexes to real ports and watching link up/down.

Key IF-MIB OIDs

The IF-MIB splits across two tables. ifTable (1.3.6.1.2.1.2.2.1) holds the classic 32-bit columns and the descriptive fields; ifXTable (1.3.6.1.2.1.31.1.1.1) holds the 64-bit counters and extras like ifName and ifHighSpeed. Both are indexed by ifIndex, so a single walk lines the two up per interface.

ObjectOIDWhat it gives you
ifDescr1.3.6.1.2.1.2.2.1.2Interface name/description
ifOperStatus1.3.6.1.2.1.2.2.1.8Link state (up/down/testing)
ifInOctets1.3.6.1.2.1.2.2.1.1032-bit inbound byte counter
ifInErrors1.3.6.1.2.1.2.2.1.14Inbound errored packets
ifOutErrors1.3.6.1.2.1.2.2.1.20Outbound errored packets
ifHCInOctets1.3.6.1.2.1.31.1.1.1.664-bit inbound byte counter
ifHCOutOctets1.3.6.1.2.1.31.1.1.1.1064-bit outbound byte counter
ifHighSpeed1.3.6.1.2.1.31.1.1.1.15Link speed in Mbps

Walk a whole table with snmpwalk -v2c -c public <host> 1.3.6.1.2.1.2.2.1, or grab a single leaf per interface with snmpget once you know the ifIndex.

Diagram of the IF-MIB ifTable and ifXTable mapping per-interface counters to an external SNMP poller

Frequently asked questions

Why do I get a bandwidth number that makes no sense?

Almost always a counter wrap. A 32-bit octet counter rolls over in seconds on a gigabit link, so the delta between two polls goes negative or absurd. Switch to the 64-bit ifHCInOctets / ifHCOutOctets in ifXTable and the problem disappears.

How do I turn octet counters into a bit-per-second rate?

Poll the counter twice, subtract the earlier value from the later, multiply the byte delta by 8, and divide by the seconds between polls. Divide that rate by the link speed from ifHighSpeed for a utilization percentage.

How do I know which ifIndex is which physical port?

Read ifDescr and ifName from the same walk — they map each numeric ifIndex to a human name. ifAlias carries any custom label configured on the device. Note that indexes can change across a reboot on some platforms.

Does external monitoring collect interface data by default?

Yes. Network interface counters are part of ostr.io's default health check — it polls the IF-MIB from outside your network and alerts by email and SMS when throughput, errors, or link state cross your thresholds.

Conclusion

Network interface monitoring is SNMP at its most reliable: one standard MIB, portable OIDs, and every metric you need for throughput, saturation, errors, and link state. The two rules that matter are simple — treat traffic objects as counters and compute deltas, and use the 64-bit ifXTable counters (1.3.6.1.2.1.31.1.1.1) on anything faster than a slow link so you never chart a wrap as a spike. Start with bandwidth, traffic, errors, or interface info, then poll from outside with ostr.io Monitoring so a saturated or flapping link reaches you even when the box itself is struggling. The full menu lives in the sensor & OID catalog.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.