--- type: Topic Hub title: "SNMP Network Interface Monitoring — Bandwidth, Traffic & Errors" description: "Poll interface throughput, bandwidth load, packet errors and link state over SNMP using the IF-MIB, with real 64-bit counter OIDs and external alerting." resource: "https://snmp-monitoring.com/sensors/network/" tags: [sensors, snmp] timestamp: 2026-07-13T00:00:00Z --- # 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](/sensors/network/bandwidth-load.md) — turn octet counters into a utilization percentage against `ifSpeed` / `ifHighSpeed`, and alert on sustained saturation. - [SNMP Interface Traffic](/sensors/network/interface-traffic.md) — the raw in/out throughput read from `ifHCInOctets` and `ifHCOutOctets`, with delta calculation. - [SNMP Interface Errors](/sensors/network/interface-errors.md) — `ifInErrors` (`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](/sensors/network/interface-info.md) — 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. | Object | OID | What it gives you | |---|---|---| | `ifDescr` | `1.3.6.1.2.1.2.2.1.2` | Interface name/description | | `ifOperStatus` | `1.3.6.1.2.1.2.2.1.8` | Link state (up/down/testing) | | `ifInOctets` | `1.3.6.1.2.1.2.2.1.10` | 32-bit inbound byte counter | | `ifInErrors` | `1.3.6.1.2.1.2.2.1.14` | Inbound errored packets | | `ifOutErrors` | `1.3.6.1.2.1.2.2.1.20` | Outbound errored packets | | `ifHCInOctets` | `1.3.6.1.2.1.31.1.1.1.6` | 64-bit inbound byte counter | | `ifHCOutOctets` | `1.3.6.1.2.1.31.1.1.1.10` | 64-bit outbound byte counter | | `ifHighSpeed` | `1.3.6.1.2.1.31.1.1.1.15` | Link speed in Mbps | Walk a whole table with `snmpwalk -v2c -c public 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](https://snmp-monitoring.com/img/sensors/network-interfaces.webp) ## FAQ **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](/sensors/network/bandwidth-load.md), [traffic](/sensors/network/interface-traffic.md), [errors](/sensors/network/interface-errors.md), or [interface info](/sensors/network/interface-info.md), then poll from outside with [ostr.io Monitoring](https://ostr.io/service/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](/sensors/index.md).