Wondering where your link capacity goes? Bandwidth monitoring answers that by polling interface counters for how busy a link is, then using flow data to see who is driving it.
This guide sits under our network monitoring overview.
| Item | Value |
|---|---|
| High-capacity counters required (IF-MIB) | Interfaces faster than 20 Mbps |
| 32-bit ifInOctets wrap on 1G at line rate | About 34 seconds |
| 32-bit ifInOctets wrap on 10G at line rate | About 3.4 seconds |
| 64-bit counter for inbound octets | ifHCInOctets (.1.3.6.1.2.1.31.1.1.1.6) |
| Counter discontinuity object | ifCounterDiscontinuityTime (.1.3.6.1.2.1.31.1.1.1.19) |
The figures come from a March 2026 OneUptime guide and a Netdata guide. They can change, so check the sources before you rely on them.
What bandwidth monitoring measures
Bandwidth monitoring measures how much traffic crosses an interface over time, compared with the interface’s capacity. The result is usually shown as bits per second and as a percentage of link speed.
Two questions get mixed up. The first is “how full is this link?”, and the second is “what is filling it?”. Different data answers each one.
- Counters (SNMP) tell you how busy each interface is and how that changes over days.
- Flow records (such as NetFlow) tell you which hosts, ports or applications make up the traffic.
- Latency and loss show whether a busy link is hurting users; see network latency for that side.
How counter polling works
Each interface keeps running totals of octets (bytes) sent and received. A poller reads the total, waits an interval, reads it again, and takes the difference.
Convert the octet difference to bits, divide by the interval in seconds for a rate, and divide again by the interface speed for a utilisation percentage.
- Find the interface index, for example by walking ifDescr.
- Poll the in and out octet counters at a fixed interval.
- Subtract the previous reading, convert octets to bits, and divide by the seconds elapsed.
- Compare with the interface speed to get percent utilisation.
Keep inbound and outbound separate. Most links are full duplex, so a link can be saturated in one direction while the other sits nearly idle, and a combined figure hides that.
Record the timestamp of each poll rather than assuming the interval was exact. Pollers get delayed, and dividing by the planned interval instead of the real one distorts the rate.
Shorter intervals catch bursts but create more polling load and more data. Longer intervals smooth peaks away, so a link can look healthy while it saturates for a minute at a time.
Where you poll matters as much as how. Monitor the uplinks, the internet edge and links between sites first, because those are shared and expensive. Access ports rarely need per-minute attention unless a user complains.
Also decide which direction you care about. On an internet edge, inbound usually reflects downloads and streaming, while outbound reflects uploads, backups and cloud sync, and each can be the bottleneck on its own.
Why 64-bit counters matter
The original 32-bit counters wrap to zero quickly on fast links. According to Netdata’s guide, a 32-bit ifInOctets counter on a 1G interface wraps every ~34 seconds at line rate, and on 10G about every 3.4 seconds.
If your polling interval is longer than the wrap time, a wrap can go unnoticed and your graph shows nonsense. The fix is to poll ifHCInOctets and ifHCOutOctets, the high-capacity counters. The OneUptime guide notes that IF-MIB requires high-capacity octet counters for compliant interfaces faster than 20 Mbps.
Check your tool’s settings too. Some pollers default to the older counters for compatibility, so confirm which object each graph actually reads. A quick snmpwalk against the interface table shows whether the device exposes the high-capacity objects at all.
Spotting false spikes after reboots
A device reboot resets counters to zero, and naive subtraction then gives an impossible negative or huge value. These show up as sudden spikes on graphs.
Per the Netdata guide, RFC 2863 says a management application must discard any calculated difference for which ifCounterDiscontinuityTime differs between two polls. Older agents may not implement that object, so also watch for a sysUpTime that goes backwards.
A practical habit is to sanity-check any spike that is larger than the interface could physically carry. If a graph shows more traffic than the link speed allows, the cause is a measurement error, not a real burst, and the reading should be dropped rather than alerted on.
Missed polls create a similar problem. When a poll fails, the next successful one covers a longer span, so good tools either skip the gap or spread the difference sensibly instead of drawing a false peak.
Setting baselines and alerts
A utilisation number means little without context. Collect a few weeks of data first, so you know what a normal Monday morning looks like on each link.
Then alert on deviation from that baseline and on sustained high utilisation, not on a single reading. One brief peak is usually harmless, while a link that stays near its ceiling for a long stretch is where queues build and users notice.
- Alert on sustained utilisation, for example a threshold that must hold across several consecutive polls.
- Alert on a sudden drop to zero, which often means a link or device failure rather than quiet traffic.
- Track growth over months so you can plan an upgrade before the link is full.
- Review interface errors and discards alongside utilisation, since a clean percentage can still hide a faulty cable.
Treat the thresholds as a starting point and tune them. A backup link that is idle by design needs different rules from a busy internet uplink.
Finding what is using the capacity
Once counters show a busy link, switch to flow data to attribute the traffic. Sort by source, destination, port and application, then look at the top few entries.
- Check whether the load is steady (backups, streaming) or bursty (updates, a misbehaving host).
- Compare the time of the peak with scheduled jobs.
- Confirm the link speed configured in your tool matches reality, since a wrong speed skews every percentage.
When you find a top talker, ask whether the traffic is legitimate before you act. A large transfer to a known backup target is normal, whereas steady outbound traffic from a workstation to an unfamiliar address deserves a closer look.
Fixes tend to fall into a few groups: schedule heavy jobs outside working hours, shape or prioritise traffic by class, move a chatty service to a different segment, or add capacity when demand has genuinely outgrown the link. Measure again after each change so you know whether it worked.
Counters and flows are collected differently, so their totals rarely match exactly. Compare them over longer windows. For choosing what else to track, see network monitoring metrics.
Frequently asked questions
What is the difference between ifInOctets and ifHCInOctets?
Show answer
ifInOctets is a 32-bit counter that wraps quickly on fast links. ifHCInOctets is the 64-bit version, suited to links faster than 20 Mbps.
Does SNMP tell me which user is using bandwidth?
Show answer
No. SNMP counters show per-interface totals. You need flow data or packet capture to see hosts and applications.
Why does my graph show a huge spike after a reboot?
Show answer
Counters reset to zero on reboot, so the difference between two polls is wrong. Discard readings where the discontinuity time changed.
How often should I poll?
Show answer
Pick an interval short enough to catch the bursts you care about, and use 64-bit counters so wraps are not a risk.
