SNMP Interface Traffic

Every byte that leaves or enters a network port gets counted, and SNMP interface traffic monitoring is how you read those counters without ever touching the device. It's the bread-and-butter metric of network operations: how much data is actually flowing through each interface, right now and over time. This page covers what the octet counters really measure, the exact ifXTable OID that holds the 64-bit versions, why the old 32-bit counters wrap and lie to you, how to poll them by hand, and how to turn raw counter values into a throughput graph you can trust.

What is Interface Traffic and why monitor it

Interface traffic is the volume of data crossing a network interface — a physical NIC, a virtual adapter, a switch port. SNMP doesn't hand you a neat "megabits per second" figure. Instead the agent exposes a running total: a counter that only ever climbs, ticking up one unit for every octet (byte) received or sent since the interface last reset. Two reads, a little arithmetic, and that total becomes a rate.

Why bother watching it? Because traffic is the pulse of the box. A link that's suddenly maxed out explains slow page loads, stalled backups, and timeouts that no CPU graph would ever reveal. A link that's gone dead flat when it should be busy is often the first sign of a failed upstream, a flapping cable, or a service that quietly stopped. Traffic tells you whether the pipe is doing its job.

The symptoms it surfaces are practical ones. Saturation during business hours points at an undersized uplink. A nightly spike that overruns the window points at a backup that's outgrown its slot. Wildly asymmetric in/out volume on a server that should be balanced can hint at exfiltration or a runaway upload. None of that shows up unless you're recording the counters and watching the deltas. That's the whole case for SNMP interface traffic monitoring — cheap to collect, and it catches problems the host itself won't complain about.

The OID: 1.3.6.1.2.1.31.1.1.1

The OID you want is 1.3.6.1.2.1.31.1.1.1 — the ifXTable (interface extensions table) from the IF-MIB, defined in RFC 2863. This is the modern table, and it exists for one very specific reason: the original counters were too small. Inside it live the high-capacity octet counters, ifHCInOctets at column .6 and ifHCOutOctets at column .10, each a 64-bit Counter64 of total bytes in and out per interface. There's also ifHighSpeed at .15, the interface's rated speed expressed in megabits per second.

Here's the bit that trips people up. The old ifTable (1.3.6.1.2.1.2.2.1) carries 32-bit ifInOctets .10 and ifOutOctets .16. A 32-bit counter tops out at about 4.29 billion octets, then rolls back to zero. On a gigabit link fully loaded, that wrap happens in roughly 34 seconds — faster than most polling intervals — so you can miss whole wraps and compute nonsense rates. The 64-bit Counter64 in ifXTable is the fix: it won't realistically wrap in the life of the hardware. On any modern high-speed interface, poll the high-capacity counters. Always.

How to query it

Any Net-SNMP client reads this fine. These examples assume an agent running SNMPv2c with a read-only community; if you haven't set that up yet, the snmpd.conf guide walks through it.

1. Walk the inbound octet counters across every interface:

   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.31.1.1.1.6
   

   Sample output — one line per interface index:

   IF-MIB::ifHCInOctets.1 = Counter64: 0
   IF-MIB::ifHCInOctets.2 = Counter64: 84739201655
   

2. Read one interface when you already know its ifIndex:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.31.1.1.1.6.2 1.3.6.1.2.1.31.1.1.1.10.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.31.1.1.1.6
   

Now the arithmetic. A single read is meaningless — the counter is just a big number. To get a rate, poll twice, subtract, and divide by the seconds between polls: bits_per_second = (octets_now − octets_before) × 8 ÷ seconds_elapsed. Multiply octets by 8 because you want bits, and interfaces are rated in bits per second. Poll ifHCInOctets and ifHCOutOctets on a steady cadence, keep the previous sample, and each interval produces one throughput data point. One catch worth remembering: if the counter went down between reads, the interface reset or wrapped, so discard that sample rather than graph a negative spike.

Normal vs alarming values & thresholds

There's no universal "too much traffic" number — a 10G uplink and a 100M management port live in different worlds — so express thresholds as a percentage of the interface's rated speed (ifHighSpeed) rather than raw bits. A few bands hold up almost everywhere:

• 0–50% of link speed, sustained — healthy headroom, normal operating range.
• 50–75% sustained — busy but fine; worth a warning-level trigger if it holds during peak hours.
• 75–90% sustained — approaching saturation; latency and jitter usually start creeping up. Treat as high priority.
• 90–100% sustained — the pipe is full and packets are queuing or dropping. Page someone.
• A flatline at zero when traffic is expected — often worse than a spike; the link may be down, not idle.

Two habits keep these thresholds honest. First, alert on sustained load, not a single sample — a five-minute backup burst to 100% is the link doing its job, not an incident. Second, baseline each interface against its own rhythm; a link that lives at 60% every afternoon is telling a different story than one that just jumped there for the first time.

Alerting on this metric externally

Reading ifHCInOctets on demand tells you the link is busy this second. What actually prevents an outage is being told when a saturated or dead link stays that way — and that's exactly where on-host tooling has a blind spot. If the uplink is congested or down, an alerting agent living on that same box may not be able to get its warning out at all. The message needs the very pipe that's broken.

Polling from outside sidesteps that. It's the idea behind double durability: an independent watcher keeps reading the counters even when the network path home is degraded, so a maxed-out interface still trips an alert. SNMP is a pull protocol, so the external poller just reads 1.3.6.1.2.1.31.1.1.1 on its own schedule and tests the threshold on its own hardware.

That's the practical shape of ostr.io Monitoring: it polls your interface counters from outside your network and fires real-time email and SMS alerts the moment throughput crosses your limit — so a congested link reaches you even when it can't carry your own alert traffic.