How to Monitor Bandwidth & Throughput Utilization via SNMP

By the SNMP Monitoring team · Reviewed July 2026

"We're pushing 400 Mbps" means nothing until you know the link speed. On a 10 Gbit uplink that's a yawn; on a 500 Mbit circuit it's four-fifths gone and you're about to start dropping packets. Bandwidth monitoring is the step past raw throughput: you take the bits-per-second you measured from the counters and divide by the link's capacity to get a percentage. Percent is what you alert on, what you trend, and what you take to a capacity-planning meeting — because it's the only number that's comparable across a 100 Mbit access port and a 40 Gbit core link.

This is the how-to for utilization. Raw octet-to-bps mechanics get their own page so this one doesn't repeat them — see interface traffic. Full object reference: interface OIDs. Parent: network monitoring.

The utilization formula

Three inputs, one division:

1. Δoctets — the change in an octet counter between two polls (from interface traffic). Use the 64-bit ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) or ifHCOutOctets (…31.1.1.1.10) on anything gigabit or faster.
2. Δseconds — the actual wall-clock time between those two reads.
3. Capacity in bps — from ifHighSpeed (1.3.6.1.2.1.31.1.1.1.15), which reports Mbit/s, so multiply by 1,000,000.

Then:

Utilization % = (Δoctets × 8) ÷ (speed_bps × Δseconds) × 100
     where speed_bps = ifHighSpeed × 1,000,000

Worked example. A 1 Gbit port (ifHighSpeed = 1000, so speed_bps = 1,000,000,000). ifHCInOctets climbs by 937,500,000 bytes over 10 seconds:

• bits moved = 937,500,000 × 8 = 7,500,000,000
• capacity over the window = 1,000,000,000 × 10 = 10,000,000,000
• utilization = 7,500,000,000 ÷ 10,000,000,000 × 100 = 75%

Seventy-five percent inbound. That's a link you should be watching, not one you should be ignoring.

Inbound versus outbound

Bandwidth is directional and rarely symmetric — a file server pushes far more out than in, a backup target does the reverse. Track both and alert on both. The two directions use separate counters, so it's just the same formula run twice.

Note also that a full-duplex link has separate capacity each way — a 1 Gbit port can do a gigabit in and a gigabit out simultaneously. So compute each direction against the same ifHighSpeed, but don't add them together and call it "2 Gbit of usage." They're independent lanes.

Setting saturation alerts

Utilization alerts go wrong when they fire on a single spike. A backup kicks off, one poll reads 99%, someone gets paged, the backup finishes, nothing was actually broken. Do it on sustained usage instead:

• Warn when utilization holds above ~80% across several consecutive polls — enough that it's a trend, not a burst.
• Critical when it stays near capacity (say ≥95%) for a sustained window, which is where you start losing packets to discards.
• Ignore brief bursts to capacity that clear on the next poll — normal traffic is spiky.
• Alert per direction; a link can be fine inbound and jammed outbound.

That "sustained" qualifier is the whole game. A momentary 100% is traffic doing its job. A link glued at 90% for an hour every evening is a capacity problem wearing a schedule.

The 95th percentile

Peaks lie in both directions — a single spike overstates a link and a single quiet second understates it. The industry answer, and the way most transit is billed, is the 95th percentile:

1. Sample utilization on a fixed interval (classically every 5 minutes) across a billing period, usually a month.
2. Sort all the samples.
3. Discard the top 5% — the busiest bursts.
4. The highest value remaining is your 95th-percentile figure.

The idea is to charge for (and plan around) sustained demand while forgiving short spikes. If your 95th percentile on a link is creeping toward its capacity month over month, that's your early-warning that it's time to upgrade — long before users feel it.

Reading the inputs with snmpbulkwalk

Grab the counter and the speed in the same pass, then diff the counter across two polls:

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

IF-MIB::ifHighSpeed.1 = Gauge32: 1000
IF-MIB::ifHighSpeed.2 = Gauge32: 10000
IF-MIB::ifHighSpeed.3 = Gauge32: 1000

So index .2 is a 10 Gbit port, the others gigabit. Now pull the matching octet counter twice:

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

Line up by ifIndex, apply the formula per port, and you have utilization for the whole device. <RO_string> is a placeholder — never commit a live community. Feed the result into a dashboard like Grafana for trending.

Capacity planning

Utilization isn't only an alert — it's the raw material for knowing when to buy. Good practices:

• Keep long-horizon trends, not just live graphs — a month or a year of 95th-percentile per link.
• Watch the slope, not the value. A link at 40% climbing 3 points a month tells you more than one sitting flat at 70%.
• Correlate the busy direction with what the link actually serves before you upgrade — the fix might be moving traffic, not adding bandwidth.
• Flag anything whose 95th percentile crosses ~70–80% as a planning candidate, well ahead of the alert threshold.

Reference & related

This page is the utilization how-to. For object types and the complete interface column list, use the reference twin: interface OIDs. Closely related how-tos: interface traffic for the counter mechanics and port speed for the capacity term. Definitions at glossary.

Frequently asked questions

How do I calculate bandwidth utilization with SNMP?

Take the change in an octet counter between two polls, multiply by 8 for bits, and divide by the link capacity in bits per second times the seconds between polls, then times 100. Capacity comes from ifHighSpeed (Mbit/s) × 1,000,000.

Which OIDs do I need for bandwidth?

Three: ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) and/or ifHCOutOctets (…31.1.1.1.10) for the traffic counters, and ifHighSpeed (…31.1.1.1.15) for the link capacity. Use the 64-bit ifHC counters on any gigabit-plus link so they don't wrap.

What is a good utilization alert threshold?

A common pattern is a warning around 80% and a critical around 95%, both required to hold across several consecutive polls rather than firing on one spike. Tune per link — an access port and a core uplink don't warrant the same sensitivity.

What is 95th percentile billing?

You sample utilization at a fixed interval over the billing period, drop the busiest 5% of samples, and use the highest remaining value. It charges for sustained demand while forgiving short bursts, which is why most transit and metered links are billed this way.

Key takeaways

• Utilization = (Δoctets × 8) ÷ (speed_bps × Δseconds) × 100, with speed_bps = ifHighSpeed × 1,000,000.
• Needed OIDs: ifHCInOctets, ifHCOutOctets, ifHighSpeed — 64-bit counters on gigabit+.
• Track in and out separately; full-duplex links have independent capacity each way.
• Alert on sustained high usage, not single spikes; use the 95th percentile for planning and billing.
• Trend the slope over months to see upgrades coming before users do.
• Types and columns: interface OIDs; an off-box external check via external monitoring keeps paging when the site drops.