SNMP Bandwidth Monitoring

SNMP bandwidth monitoring answers a question raw byte counts never quite do: not "how much data moved" but "how close is this link to full?" It's the difference between a number and a verdict. A gigabit uplink pushing 200 Mbps is idling; a 100 Mbps link pushing the same 200 Mbps is impossible — it's already dropping packets. Bandwidth utilization puts throughput in the context of capacity, and that ratio is what actually drives network load monitoring and traffic alerting. This page covers how utilization is derived, which OIDs feed it, how to compute the percentage by hand, and where to draw the line that fires an alert.

What is Bandwidth and why monitor it

Bandwidth, strictly, is capacity — the maximum rate a link can carry, its speed limit. In everyday operations "bandwidth monitoring" usually means watching utilization: how much of that capacity is being consumed at any moment, expressed as a percentage. Throughput is the raw rate in bits per second; utilization is that rate divided by the link's rated speed. The percentage is what tells you whether you're fine or in trouble.

Why watch it? Because saturation is invisible until it hurts. A link creeping toward 100% doesn't announce itself — it just starts adding latency, then jitter, then packet loss, and suddenly voice calls break up and page loads stall for reasons no application log explains. Utilization catches that trend early, while there's still time to add capacity or shift traffic.

The symptoms it surfaces are the ones users feel first. An uplink pegged at peak hours means the pipe is undersized for the workday. A backup job that overruns its window is usually a link saturated past its scheduled slot. Chronic high evening utilization on a residential-style link points at contention you can plan around. The point of network load monitoring is to see the pipe filling before it overflows — not to read the wreckage afterward. That early warning is the entire value proposition, and it's cheap to collect over SNMP.

The metric behind it: derived from octet counters and link speed

Here's the thing that surprises people: there is no single "bandwidth utilization" OID. No agent hands you "73% full." Utilization is a derived metric — you compute it from two ingredients the device already exposes.

The first ingredient is throughput, which you get from the interface octet counters over time. The second is the link's rated speed, so you know what to divide by.

All of these come from the IF-MIB (RFC 2863). The octet counters are the same 64-bit Counter64 values covered in detail on the interface traffic page — use the high-capacity ifXTable versions, not the 32-bit ifTable ones, which wrap in seconds on a fast link and wreck your math. For the denominator, prefer ifHighSpeed (.15) at Mbps resolution; fall back to ifSpeed (.5) only on older, slower interfaces where 32 bits still fits. Utilization is then just rate over capacity, times 100.

How to query it

You collect the same OIDs an SNMPv2c agent already publishes, then do the arithmetic. If the agent isn't configured yet, start with the snmpd.conf guide.

1. Read the link's rated speed (the denominator) for interface index 2:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.31.1.1.1.15.2
   

   IF-MIB::ifHighSpeed.2 = Gauge32: 1000
   

2. Sample the inbound octet counter twice, a known interval apart:

   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.31.1.1.1.6.2
   # wait 30 seconds
   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.31.1.1.1.6.2
   

3. Compute utilization from the two samples and the speed:

   rate_bps      = (octets_2 - octets_1) * 8 / seconds_elapsed
   capacity_bps  = ifHighSpeed * 1000000
   utilisation_% = rate_bps / capacity_bps * 100
   

So a delta of 3,750,000,000 octets over 30 seconds is 3.75e9 * 8 / 30 = 1,000,000,000 bps = 1 Gbps. On a 1000 Mbps link that's 100% — the pipe is full. Do the same for ifHCOutOctets to get outbound load. Most polling stacks fold these steps in for you, but the math is worth knowing so the numbers on your dashboard mean something.

One decision people gloss over is which direction to alert on. Inbound and outbound utilization are independent — a link can be near-idle downloading while saturated uploading, or the reverse — so treat them as two separate series rather than summing them into one figure. A backup server pushing data offsite lives on its outbound line; a file server handing downloads to clients lives on its inbound. Averaging the two hides the one that's actually in trouble. And mind the polling interval: a 64-bit counter sampled every five minutes gives you the average utilization over those five minutes, which can smooth a 30-second saturation burst down to a comfortable-looking 40%. If short spikes matter to you — and for latency-sensitive traffic they do — poll more often so the peaks survive into the graph.

Normal vs alarming values & thresholds

Because utilization is already normalized to a percentage of capacity, the thresholds travel well across links of any speed. These bands are a sane starting point for traffic alerting:

• 0–50% sustained — healthy headroom. The link is comfortable.
• 50–70% sustained — normal-busy; fine, but start watching the trend.
• 70–85% sustained — approaching saturation. Latency and jitter often begin here; a warning-level trigger belongs in this band.
• 85–95% sustained — congested. Queuing and drops are likely; treat as high priority.
• 95–100% sustained — the link is full and packets are being lost. Page someone and plan capacity.

Two rules keep bandwidth alerts credible. First, alert on sustained utilization, not on a single sample — a 30-second burst to 100% during a backup is expected, and paging on it just trains people to ignore the pager. Require the level to hold for several minutes. Second, baseline each link against its own daily rhythm; a WAN link that lives at 75% every afternoon is a different story from one that just spiked there, and a flat one-size threshold can't tell them apart.

Alerting on this metric externally

Utilization tells you the pipe is filling. The alert that matters is the one that reaches you when it's already full — and that's precisely when an on-host or on-network alerter struggles, because its warning has to travel over the very link that's saturated or down. A congested uplink can delay or drop the alert about the congestion. That's a bad time to depend on it.

Polling from outside removes the dependency. It's the logic of double durability: an independent checker reads the counters and computes utilization from beyond your network, so a maxed-out link still trips an alert even when it can't carry your internal monitoring traffic. Because SNMP is pull-based, the external poller just reads the octet counters and ifHighSpeed on its own schedule and does the arithmetic on its own hardware — the saturated link doesn't have to cooperate.