Summary

  • SNMP's original 32-bit counter was designed to wrap from its maximum back to zero. A smaller second reading could therefore be normal arithmetic, not reversed traffic or a failed interface.
  • Faster links made 32-bit wrap intervals too short for dependable polling. The Interfaces MIB added 64-bit high-capacity counters but retained the low 32 bits for older managers.
  • Width did not solve resets. sysUpTime and ifCounterDiscontinuityTime define the measurement epoch; if either shows a break between polls, the calculated traffic delta must be discarded.

The counter fell while the link kept carrying traffic

Imagine polling a 1 Gb/s interface. The first reading is close to 4.3 billion octets. The next is a much smaller number, although packet forwarding never stopped. Subtracting the ordinary integers produces a negative result. Treating the decrease as a reset erases traffic. Treating every decrease as one wrap can invent traffic after a restart.

This was not an edge case left to dashboards. It was built into the earliest Internet management type. A counter represented accumulated events in a finite number space. To turn two readings into a rate, a manager needed more than both numbers: it needed the counter's width, the time between observations and evidence that both samples belonged to the same measurement history.

The distinction is easy to lose because charts display one continuous line. The protocol record is less forgiving. It separates an object's identity from the epoch during which its values can be compared.

Wrap was built into the first counter

RFC 1155, published in 1990, defined Counter as a non-negative integer that increases monotonically until 2^32-1, then wraps and resumes from zero. Wrap was the normal successor to the largest value. It did not mean that the device had moved backward, lost every byte, or revoked a previous observation.

RFC 1213 made that type familiar through MIB-II. Interface rows carried ifInOctets, ifOutOctets and packet counters. The same MIB exposed sysUpTime and ifLastChange, providing time and state context around the readings. Yet the raw counter did not say when it had begun or how many cycles had already passed.

SMIv2 later stated the evidentiary limit explicitly. In RFC 2578, Counter32 and Counter64 have no defined initial value. One isolated sample therefore has, in general, no information content. Both types wrap; they differ in how long the number space lasts.

Within an uninterrupted epoch, one known wrap can be handled with modular arithmetic. Across a gap long enough for several wraps, two endpoint values cannot reveal how many cycles occurred. Numeric correctness depends on a bound outside the number itself.

Speed turned width into a polling deadline

The finite width became operationally expensive as links accelerated. RFC 1573 calculated that a stream of back-to-back full-size packets could wrap a 32-bit octet counter in just over 57 minutes on 10 Mb/s Ethernet, about 5.7 minutes on FDDI, and roughly 34 seconds on a 1 Gb/s medium. RFC 2863 preserved the same warning for the later Interfaces MIB.

Polling faster was not an unlimited answer. Every shorter interval consumed management bandwidth and processing, and a missed cycle could still make the reconstruction ambiguous. The working group considered scaling the unit—counting blocks of octets instead of individual octets—but rejected it. At low traffic rates a scaled counter would wait for a whole block before moving, making steady traffic appear bursty.

The chosen compromise was a wider type. RFC 1573 introduced high-capacity groups with 64-bit counters. RFC 2863 tied support to interface speed: 32-bit byte and packet counters at 20 Mb/s or below; 64-bit octet counters above 20 Mb/s; and 64-bit packet as well as octet counters at 650 Mb/s or faster.

Those thresholds were engineering compromises, not a claim that one bit rate creates truth. They balanced the cost and then-uneven availability of 64-bit management against the shrinking time in which a 32-bit value remained unambiguous.

Wider counters kept the old window visible

The migration did not delete the old objects. When a high-capacity counter is present, RFC 1573 and RFC 2863 require the associated 32-bit counter to remain available as its low 32 bits. An older manager can still read the interface; a newer manager can retain a much longer observation window.

Compatibility therefore preserved two views of the same accumulated events. The values agree modulo 2^32, but they do not offer equal evidence over a long polling gap. A collector that silently switches from ifInOctets to ifHCInOctets can change the meaning of its historical series even though the physical link and object label remain unchanged.

Nor is Counter64 an infinite ledger. RFC 2578 defines it to wrap at 2^64-1. Its wider space makes ordinary wrap rare at the rates considered by those documents; it does not make restarts, missed observations or semantic changes disappear.

An interface name could outlive its measurements

Width solves only cyclic exhaustion. Hardware can be removed and returned. A line card can be reset while the agent stays up. An interface that operators recognize as the same logical port may deserve the same ifIndex, even though its old hardware counter values cannot be retained.

Earlier interface-table practice forced an awkward choice: preserve every counter while the interface was absent, or allocate a new index so a manager would not join the old and new values. RFC 2233 introduced a third option: retain the interface identity and expose that its measurement epoch changed.

The object was ifCounterDiscontinuityTime. RFC 2863 defines it as the sysUpTime value on the most recent occasion when one or more associated interface counters suffered a discontinuity. If none has occurred since the management subsystem was reinitialized, the value is zero.

That separation is the mechanism's lasting contribution. Stable ifIndex means that the row still names the interface within the relevant management scope. It does not guarantee that today's count continues yesterday's accumulation.

A timestamp marked the break, not the cause

The manager's rule is unusually direct. When calculating a difference between two polls, it must discard that difference if ifCounterDiscontinuityTime differs. It must also check sysUpTime, because an agent reinitialization can reset the larger naming and timing context.

Discarding a delta is not declaring zero traffic. It is saying that the standard evidence no longer supports one exact total across that interval. An operator may estimate the missing period for planning, but the estimate should not be stored as if it were the counter's observation.

The timestamp is also deliberately bounded. It records when the agent last declared a break, not why. It does not say whether a line card was replaced, software was upgraded, an object was recreated or an implementation behaved incorrectly. RFC 3635 carries the same discontinuity boundary into Ethernet-specific counters without turning it into a diagnostic cause code.

That is why an unchanged marker is useful but not magical. It supports comparison under the defined model; it does not certify the agent, authenticate the sample or prove that the counter describes the layer a downstream analyst assumed.

Sources and evidence limits

The closed historical record for this account is RFC 1155, RFC 1213, RFC 1573, RFC 2233, RFC 2578, RFC 2863 and RFC 3635. They establish syntax, lineage and manager obligations. They do not measure current product conformance, explain a live discontinuity, validate an invoice or prove that counted traffic reached its destination.