SNMP counter to bit rate calculator: octets to bits per second and utilization

Two readings of an interface octet counter, the seconds between them and the counter size are enough to work out how much traffic crossed a port and at what average rate. Add the interface speed and the calculator also gives utilization and the time a 32-bit and a 64-bit counter need to wrap at full load, which is the number that decides how often you have to poll.

How it works

Octet counters in IF-MIB (RFC 2863) count bytes since the agent started: ifInOctets and ifOutOctets as 32-bit values, ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6) and ifHCOutOctets as 64-bit values. They only go up. When one reaches its maximum it rolls over to zero and keeps counting. A rate is the difference between two readings divided by the time between them:

delta        = second reading - first reading
               if delta < 0, 32-bit: delta = delta + 2^32   (assume one wrap)
               if delta < 0, 64-bit: reset, no rate
bytes/s      = delta / seconds
bits/s       = bytes/s * 8
utilization  = bits/s / (speed in Mbit/s * 1,000,000) * 100
wrap time    = 2^bits * 8 / (speed in Mbit/s * 1,000,000)   seconds at line rate

2^32 = 4,294,967,296
2^64 = 18,446,744,073,709,551,616

Commas and spaces in the readings are ignored, so you can paste numbers straight from a graph tooltip. Both readings must be between zero and the counter maximum, and the interval must be above zero. Three notes can appear under the result:

• On a 32-bit counter, when the second reading is lower than the first, the output adds "(wrapped once)" and a note about reboots.
• When the result comes out above the interface speed, a note says more than one wrap probably happened.
• When the counter is 32-bit and the poll interval is longer than its wrap time at the given speed, a note warns that whole wraps may be missing and suggests the 64-bit counters.

Worked example

The calculator opens with a first reading of 3,912,004,118, a second of 3,949,504,118, 300 seconds between polls, a 32-bit counter and a 1,000 Mbit/s interface:

delta        = 3,949,504,118 - 3,912,004,118 = 37,500,000 octets
bytes/s      = 37,500,000 / 300              = 125,000
bits/s       = 125,000 * 8                   = 1,000,000
utilization  = 1,000,000 / 1,000,000,000 * 100 = 0.1 %
32-bit wrap  = 4,294,967,296 * 8 / 1,000,000,000 = 34.36 s

Under the output sits a note: "At this interface speed a 32-bit counter can wrap in 34.4 s, less than the 5 min between these polls, so whole wraps may be missing from this result. Poll the 64-bit counters instead."

The rate is correct; the note is the line to act on. A 32-bit counter on a gigabit port can wrap in 34.4 seconds at full load, and these readings are 300 seconds apart. At 1 Mbit/s nothing went wrong. Had the port carried 500 Mbit/s for those five minutes, it would have moved 18,750,000,000 octets, enough to roll the counter over four times, and the two readings would describe only the remainder. The counter is also close to the top: after the second reading only 345,463,178 octets are left before 2^32, about 46 minutes at this rate.

Now a real wrap on a link where a 300-second poll is safe. Change the first reading to 4,200,000,000, the second to 50,000,000 and the speed to 100 Mbit/s, where a 32-bit counter needs 5 min 44 s to wrap. The delta is 2^32 minus 4,200,000,000 plus 50,000,000, which is 144,967,296 octets. The output shows "144,967,296 (wrapped once)", an average of 3.87 Mbit/s, 483,224.3 bytes per second and 3.87 % utilization, with only the note about reboots underneath. Switch to 64-bit and the same readings come back as a reset, with no rate.

Limits and gotchas

• A wrap and a reset look the same. When a switch reboots, its counters start again from zero, and the second reading is lower than the first exactly as in a wrap. On a 32-bit counter the calculator assumes one wrap. Poll sysUpTime (1.3.6.1.2.1.1.3.0) with every sample; if it went down, the agent restarted and the sample should be thrown away, not converted.
• On a 64-bit counter a lower reading is a reset, never a wrap: one would take about 4,680 years at 1 Gbit/s and about 47 years at 100 Gbit/s. The calculator shows no rate and asks you to discard the sample and use the next pair of readings.
• More than one wrap cannot be detected from two readings, which is why the calculator warns when the interval is longer than the 32-bit wrap time. The polling interval must stay well under that time at line rate: 5 min 44 s at 100 Mbit/s, 34.4 s at 1 Gbit/s, 3.4 s at 10 Gbit/s. The practical fix is the 64-bit ifHC columns, which need SNMPv2c or v3, because SNMPv1 has no Counter64 type. IF-MIB expects 64-bit octet counters on any interface faster than 20 Mbit/s. Interface counters explained walks through a five-minute poll that hides most of the traffic.
• The rate is an average. A 300-second interval turns a 20-second burst at line rate into a modest number. How short to go is a trade between detail and poller load, covered in choosing a polling interval and the polling guide.
• Interface speed is decimal: 1 Gbit/s is 1,000 Mbit/s. ifSpeed is a 32-bit gauge that tops out at 4,294,967,295 bit/s, so for 10 Gbit/s and faster read ifHighSpeed, which is already in Mbit/s.
• Utilization is per direction. A full-duplex gigabit link can carry 1 Gbit/s in and 1 Gbit/s out at the same time. Run the in and out counters separately.
• The octet counters include framing characters, so the rate runs a little above the payload an application sees.

Questions

Why does my traffic graph show a huge spike after a switch reboot?

The counters restarted from zero, and the poller treated the drop as a wrap, adding 2^32 or 2^64 to the delta. Check sysUpTime with each poll and drop any sample where it went down.

How often do I need to poll a 32-bit octet counter?

Faster than the wrap time at line rate, with margin: under 5 min 44 s on a 100 Mbit/s port, under 34.4 s at 1 Gbit/s. Above 100 Mbit/s, switch to the 64-bit counters instead of polling faster.

Should I use ifInOctets or ifHCInOctets?

ifHCInOctets wherever the device offers it. It counts the same bytes but takes thousands of years to wrap on a gigabit link. It needs SNMPv2c or v3.

Why is the calculated rate higher than the interface speed?

The counter wrapped more than once between the two readings, or the device restarted. The true rate cannot be recovered from these two numbers; poll more often or use 64-bit counters.