A bandwidth chart suddenly shows a multi-terabit spike on a 10G interface. The on-call engineer investigates and finds the link was nearly idle. The spike is a math artifact: a 32-bit SNMP counter wrapped from near its maximum value (4,294,967,295) back to zero between two polls, and the collector’s differencing algorithm produced a nonsensical delta.
Depending on how the collector handles the wrap, the symptom differs: a fake spike (when the negative delta is treated as unsigned) or a fake traffic drop to zero (when treated as signed and clamped). Both hide real traffic patterns and train operators to ignore chart anomalies, including genuine ones.
The fix is to use 64-bit HC counters (ifHCInOctets, ifHCOutOctets) for any interface at or above 100 Mbps. 32-bit counters on those interfaces cannot represent enough octets to survive a standard polling interval.
What happens during a wrap
A Counter32 is an unsigned 32-bit integer that increments monotonically to 2^32 - 1 (4,294,967,295), then wraps to zero. When a collector computes the rate between two polls, it subtracts the previous value from the current value. If the counter wrapped between polls, the subtraction yields a large negative number.
The failure mode depends on the collector’s differencing logic:
- Unsigned interpretation: the negative delta becomes a very large positive number. The chart shows terabits per second on a gigabit link.
- Signed and clamped: the negative delta is treated as zero or negative utilization. The chart shows a traffic drop during actual high utilization.
- Wrap-aware: the collector detects
current < previousand computesdelta = 2^32 - previous + current. Correct only if exactly one wrap occurred between polls. Multiple wraps produce severe underestimation.
Minimum wrap time at full line rate with back-to-back maximum-size packets:
| Interface speed | Minimum wrap time (ifInOctets, 32-bit) |
|---|---|
| 10 Mbps | ~57 minutes |
| 100 Mbps | ~5.7 minutes |
| 1 Gbps | ~34 seconds |
| 10 Gbps | ~3.4 seconds |
With a standard 5-minute polling interval, a 1 Gbps interface at moderate utilization wraps between polls. A 10G interface wraps multiple times per minute. The collector cannot distinguish one wrap from several, so the computed rate is wrong regardless of wrap-handling logic.
Common causes
| Cause | What it looks like | First thing to check |
|---|---|---|
| Collector polling 32-bit ifInOctets | Periodic spikes matching poll frequency on high-speed interfaces | Collector OID configuration |
| Polling interval exceeds wrap time | Spikes or flat-line gaps at consistent intervals | Compare interface speed and peak utilization against poll interval |
| SNMPv1 transport in use | 64-bit counters unavailable despite device support | SNMP protocol version in collector config |
| Device lacks 64-bit support | ifHCInOctets returns no data | Walk ifHCInOctets directly on the device |
| Device reports stale HC values | ifHCInOctets returns data but values do not change, or deltas do not match traffic expectations | Compare raw HC deltas against ifHighSpeed expectations |
| Differencing algorithm ignores wraps | Negative or impossibly large deltas with no wrap correction | Review collector source or config for wrap handling |
Quick checks
All read-only and safe against production devices. Replace the trailing interface index (.1) with the actual ifIndex for your target interface.
# Check which counter the collector is using (32-bit vs 64-bit)
# 32-bit ifInOctets
snmpget -v2c -c <community> <device> .1.3.6.1.2.1.2.2.1.10.1
# 64-bit ifHCInOctets
snmpget -v2c -c <community> <device> .1.3.6.1.2.1.31.1.1.1.6.1
# Check sysUpTime to distinguish counter wrap from device reboot
snmpget -v2c -c <community> <device> .1.3.6.1.2.1.1.3.0
# Check ifCounterDiscontinuityTime (zero means no discontinuity recorded)
snmpget -v2c -c <community> <device> .1.3.6.1.2.1.31.1.1.1.19.1
# Check interface speed in Mbps (ifHighSpeed)
snmpget -v2c -c <community> <device> .1.3.6.1.2.1.31.1.1.1.15.1
# Verify the device actually supports 64-bit counters
snmpwalk -v2c -c <community> <device> .1.3.6.1.2.1.31.1.1.1.6
# Confirm SNMPv1 cannot retrieve Counter64 (will fail or return wrong type)
snmpget -v1 -c <community> <device> .1.3.6.1.2.1.31.1.1.1.6.1
How to diagnose it
flowchart TD
A["Bandwidth spike on chart"] --> B{"Spike exceeds ifHighSpeed?"}
B -- "Yes, impossible" --> C{"sysUpTime changed?"}
B -- "No, plausible" --> Z["Investigate as real traffic event"]
C -- "No change" --> D{"ifCounterDiscontinuityTime non-zero?"}
C -- "Decreased" --> Y["Device rebooted; counter reset, not wrap"]
D -- "Zero" --> E{"Collector using 32-bit ifInOctets?"}
D -- "Non-zero or changed" --> X["Counter discontinuity; re-baseline"]
E -- "Yes" --> F["Counter rollover confirmed"]
E -- "No, already 64-bit" --> G["Check if device returns stale HC values"]- Confirm the spike is physically impossible. Retrieve ifHighSpeed for the interface. If the charted bandwidth exceeds ifHighSpeed in Mbps, the spike cannot be real traffic. Do not rely on ifSpeed: it is a Gauge32 that maxes out at 4,294,967,295 bps (~4.29 Gbps) and saturates on 10G and faster links.
- Check sysUpTime. Retrieve
.1.3.6.1.2.1.1.3.0and compare to the value at the last successful poll. If sysUpTime increased normally, the device did not reboot. A reboot resets all counters to zero, which is a different problem. - Check ifCounterDiscontinuityTime. Retrieve
.1.3.6.1.2.1.31.1.1.1.19.<ifIndex>. A value of zero means no discontinuity has been recorded, consistent with a counter wrap (wraps are normal counter behavior, not discontinuities). A non-zero value or a value that changed since the last poll indicates a counter reset from an interface flap or reconfiguration. - Identify which OID the collector polls. If it uses
.1.3.6.1.2.1.2.2.1.10(ifInOctets) on an interface at or above 100 Mbps, the 32-bit counter width is the problem. - Verify 64-bit counter support on the device. Walk ifHCInOctets. If it returns data, the device supports HC counters and the collector needs reconfiguration. If it returns nothing, the device lacks 64-bit support.
Things that are not counter wrap
Not every bandwidth anomaly is a counter wrap. Rule these out before applying the fix:
- Device reboot: sysUpTime decreases or resets to zero. All interfaces drop simultaneously, not just one.
- Interface flap: ifCounterDiscontinuityTime changes. The counter resets to zero for that interface only.
- SNMP response loss: the collector gets no response for one or more polls, then sees a larger-than-expected delta on the next successful poll. This is real traffic accumulated over a longer interval, not a wrap artifact. Check for gaps in the time series.
- Counter32 with single-wrap handling but high utilization: the collector computes one wrap correctly, but multiple wraps occur. The chart shows underestimated traffic, not a spike.
How to fix it
Switch the collector to HC counters. Replace ifInOctets with ifHCInOctets and ifOutOctets with ifHCOutOctets in the collector configuration.
32-bit OID 64-bit HC OID Description ifInOctets .1.3.6.1.2.1.2.2.1.10ifHCInOctets .1.3.6.1.2.1.31.1.1.1.6Inbound octets ifOutOctets .1.3.6.1.2.1.2.2.1.16ifHCOutOctets .1.3.6.1.2.1.31.1.1.1.10Outbound octets Ensure SNMPv2c or SNMPv3 transport. SNMPv1 cannot retrieve Counter64 values. If the collector is configured for SNMPv1, it will silently fall back to 32-bit counters or fail to retrieve HC OIDs.
For devices that lack HC counter support, reduce the polling interval below the minimum wrap time for that interface speed. This is a workaround, not a fix: burst traffic can still cause multiple wraps between polls even with a short interval.
Verify the fix. After switching, confirm that charted bandwidth never exceeds ifHighSpeed and that deltas are consistent across consecutive polls with no spikes or drops to zero.
Prevention
- Standardize on HC counters for all interfaces at or above 100 Mbps. Do not wait for spikes to appear.
- Use ifHighSpeed, not ifSpeed, for capacity validation and threshold-based alerts. ifSpeed saturates at ~4.29 Gbps on 10G and faster links.
- Alert on ifCounterDiscontinuityTime changes to catch interface flaps and reconfigurations separately from counter wraps.
- Review collector defaults when onboarding new devices. Some collectors default to 32-bit OIDs unless explicitly configured otherwise.
Related guides
- SNMP poller falling behind: the polling-storm cascade and how to catch it
- SNMP timeouts and retries: why devices show as down when they aren’t
- SNMP counter discontinuity after reboot: bogus rate spikes explained
- SNMP poll response latency: diagnosing a slow poller
- SNMPv3 authentication failures: authorizationError and usmStats decoded
- SNMP v2c vs v3: monitoring coverage and security trade-offs
- Network monitoring checklist: the signals every production network needs
- Silent UDP flow data loss: why your NetFlow collector is dropping records
- NetFlow v9/IPFIX template desync: flows decoded wrong or dropped after a reboot
- sFlow sampling rate: why your traffic totals are off by 1000x
- Flow export-to-ingest latency: why your NetFlow data is minutes behind
- NetFlow storage sizing: how much disk your flow collector really needs