SNMP Network Monitoring: Interfaces, Bandwidth & Errors

By the SNMP Monitoring team · Reviewed July 2026

Almost everything you'll ever graph about a network comes out of one place: the IF-MIB. Traffic, errors, link speed, up/down state — it's all a table indexed by interface, and once you can walk it you can monitor a two-port home router or a chassis switch with 400 ports the exact same way. This page is the working map: which objects matter, why the 32-bit counters lie on fast links, how to turn raw octet counts into a utilization percentage, and how to pull the whole table in one shot. Full leaf-by-leaf types live on the twin reference page interface OIDs.

Parent: monitoring.

What SNMP monitors on an interface

The IF-MIB models each interface as a row. Walk the table and every port answers the same set of questions:

• Identity — ifDescr (.2), ifName, ifType (.3)
• Capacity — ifSpeed (.5) and, for fast links, ifHighSpeed (.15)
• State — ifOperStatus (.8): is the link actually up?
• Traffic — ifInOctets (.10) / ifOutOctets (.16), bytes in and out
• Health — ifInErrors (.14) / ifOutErrors (.20), the counters that predict pain

Those octet and error objects are counters — monotonic numbers that only ever climb. You never graph the raw value; you graph the rate, the difference between two polls divided by the seconds between them. That single idea is behind every bandwidth chart you've ever stared at.

Key network metrics

The IF-MIB feeds a handful of dedicated how-to pages, each drilling into one signal:

• Interface traffic — in/out octets to bits per second
• Port speed — ifSpeed vs ifHighSpeed, negotiated rate
• Interface errors — ifInErrors / ifOutErrors, discards, drops
• Bandwidth — utilization against link capacity
• Router monitoring — uplinks, per-interface load on L3 gear
• Switch monitoring — port density, access vs trunk

Start with traffic and errors. They catch most incidents before a user does.

32-bit vs 64-bit counters

Here's the trap that bites everyone once. The classic ifInOctets is a 32-bit counter. On a busy gigabit link it can roll past its maximum and wrap back to zero in a matter of minutes — and if it wraps between two of your polls, your rate calculation goes negative or absurd. The fix arrived with SNMPv2c: the high-capacity 64-bit counters in ifXTable.

Rule of thumb: if the interface is 1 Gbit or faster, poll the ifHC counters (ifHCInOctets at 1.3.6.1.2.1.31.1.1.1.6, ifHCOutOctets at .10). Only fall back to the 32-bit objects for slow links or ancient agents that don't expose the high-capacity table.

Computing utilization

A counter is just a running total. To get "percent of the link in use," do the arithmetic:

1. Poll the octet counter twice, Δseconds apart (say 10 s).
2. Subtract to get Δoctets — bytes moved in that window.
3. Multiply by 8 to get bits.
4. Divide by capacity in bits and by the seconds:

Utilization % ≈ (Δoctets × 8) ÷ (ifSpeed × Δseconds) × 100

Worked example: ifHCInOctets climbs by 750,000,000 bytes over 10 seconds on a 1 Gbit link (ifSpeed = 1,000,000,000 bps).

(750,000,000 × 8) ÷ (1,000,000,000 × 10) × 100 = 60%

One gotcha: ifSpeed is a 32-bit value in bits per second and tops out around 4.29 Gbit. For 10 Gbit and faster, use ifHighSpeed (.15), which reports in megabits per second — so convert your capacity term to match before dividing.

Reading interfaces with snmpbulkwalk

Don't poll a big interface table with snmpwalk one Get at a time — use snmpbulkwalk, which pulls many rows per request over v2c:

snmpbulkwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.31.1.1.1.6

IF-MIB::ifHCInOctets.1 = Counter64: 48213847721
IF-MIB::ifHCInOctets.2 = Counter64: 1002934771155
IF-MIB::ifHCInOctets.3 = Counter64: 0

The trailing .1, .2, .3 are the interface indexes — the same indexes across every IF-MIB column, so ifName.2 names the port whose ifHCInOctets.2 you just read. Poll twice, diff, apply the formula. An all-zero row usually means an unused port, not a broken agent.

One habit that saves time on a big device: pull ifOperStatus (.8) alongside the octet counters so you're not computing rates for links that are administratively down. A port sitting at down(2) with flat counters is fine; a port at up(1) whose counters aren't moving is the one worth a second look. And when you're chasing a flapping or lossy link, watch the error columns — ifInErrors (.14) and ifOutErrors (.20) — as a rate against the packet counters, not as an absolute. A handful of errors on a link that's forwarded billions of frames is noise; a steadily climbing error rate is a cable, an SFP, or a duplex mismatch about to become a ticket.

Reference & devices

This page is the how-to. For the full object list, types and status enumerations, use the reference twin: interface OIDs. Vendor specifics differ in the naming and the extras they bolt on — see Cisco SNMP and MikroTik SNMP for platform notes. The complete OID index lives at all sensors; term definitions at glossary.

Frequently asked questions

How do I monitor network traffic with SNMP?

Poll the interface octet counters — ifHCInOctets / ifHCOutOctets for fast links, ifInOctets / ifOutOctets on slow ones — twice, subtract, and divide by the interval to get a rate. Multiply bytes by 8 for bits per second. Do the same for errors with ifInErrors and ifOutErrors.

What is ifInOctets?

ifInOctets (1.3.6.1.2.1.2.2.1.10) is the running count of bytes received on an interface since the agent started. It's a 32-bit monotonic counter, so you graph the difference between polls, not the raw number.

Why use 64-bit counters?

Because 32-bit counters like ifInOctets can wrap past their maximum in minutes on gigabit-plus links. If a wrap lands between two polls, the calculated rate is garbage. The 64-bit ifHC counters in ifXTable (SNMPv2c and up) effectively never wrap.

How do I calculate bandwidth utilization?

Utilization % ≈ (Δoctets × 8) ÷ (ifSpeed × Δseconds) × 100. Use ifSpeed (bps) for links up to ~4 Gbit and ifHighSpeed (Mbit/s) for faster ones, converting units so both sides match.

Key takeaways

• The IF-MIB models every interface as a table row — walk it the same way on any device.
• Traffic and errors come from counters; graph the rate, never the raw value.
• Prefer 64-bit ifHC counters on 1 Gbit+ links to dodge counter wrap.
• Utilization = (Δoctets × 8) ÷ (capacity × Δseconds) × 100; watch ifSpeed vs ifHighSpeed.
• Use snmpbulkwalk for big tables; reference types on sensors/interface.
• Pair a primary poller with an external check so a dead site still pages you.