SNMP counter rollover: fake traffic spikes from 32-bit counters

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 < previous and computes delta = 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:

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

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.3.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"]

1. 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.
2. Check sysUpTime. Retrieve .1.3.6.1.2.1.1.3.0 and 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.
3. Check ifCounterDiscontinuityTime. Retrieve .1.3.6.1.2.1.31.1.1.1.3.<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.
4. 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.
5. 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

1. 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.10	ifHCInOctets .1.3.6.1.2.1.31.1.1.1.6	Inbound octets
   ifOutOctets .1.3.6.1.2.1.2.2.1.16	ifHCOutOctets .1.3.6.1.2.1.31.1.1.1.10	Outbound octets

2. 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.

3. 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.

4. 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.