Many of the variables accessible through SNMP are counters. Counters in SNMP are never reset, and they don't have a defined starting value. So they can really only be used to measure rates: From two consecutive measurements of a counter, you can compute a rate by dividing the difference between the readings through the time interval between them. A common example are the per-interface "octet" (byte) counters for input and output traffic (ifInOctets and ifOutOctets), that have been in SNMP since the very beginning and that are used for monitoring traffic rates.
Initially, all counters in SNMP were represented using 32 bits. The SNMP standards have clearly defined that when a counter reaches its maximum representable value - in this case 232-1 - it should "wrap" to zero and continue counting from there. So a manager that polls a counter and computes a rate from subsequent measurements must be prepared to handle counter wraps correctly. Basically, if the second sampling of the counter returns a lower binary value than the first sampling, the manager assumes that the counter has wrapped exactly once, and adds 232 to the counter difference before dividing by the time interval.
The problematic situation is when a counter can wrap more than once between samples. In this case, the manager would severely underestimate the real rate. This can happen as soon as the counter increases by 232 between samples. For the typical sampling period of once every five minutes (300 seconds) and octet (byte) counters such as ifInOctets or ifOutOctets, this becomes a problem at rates above around 115 Mb/s.
Not-so-good workaround: poll more frequently
The counter wrapping problem could be addressed through more frequent sampling; but this only works within limits, and introduces other problems such as increased load on SNMP agents and errors due to SnmpUpdateLag. About the liimts: when sampling once per second (which would be excessive for most situations), double counter wraps would start to occur at rates above 34 Gb/s; and 40 Gb/s interfaces are already in production use on some networks.
Better fix: 64-bit counters
SNMPv2 and later versions include support for 64-bit integer types including counters. These 64-bit counter variables always have different object identifiers than their 32-bit counterparts (if any). In addition, 64-bit counters my not be available in all situations. For example, ifHCInOctets and ifHCOutOctets, the respective 64-bit equivalents of ifInOctets and ifOutOctets, should only be used for interfaces operating at capacities higher than 20 Mb/s according to the standard (RFC 2233).
64-bit counters can be considered reasonably future-proof: On a 100 Gb/s interface running at line rate, they will wrap once every 46.8 years. Even on a 100 Tb/s interface, wraps won't occur more frequently than every 17 days.
-- SimonLeinen - 09 Aug 2009