A poller using SNMPv1 against a multilingual SNMP agent never receives the 64-bit interface counters, and its walks skip them; what explains this?

## The one SMIv2 type SNMPv1 cannot carry SMIv2 (RFC 2578, STD 58) defines `Counter64`: a non-negative integer that increases to 2^64-1 (18446744073709551615) and then wraps to zero. RFC 2578 lets standard MIB modules use it only where the information "would wrap in less than one hour if the Counter32 type was used instead", which is why the high-capacity octet and packet counters of fast interfaces are Counter64. How fast a 32-bit counter wraps at a given line rate is a separate subject; what matters here is that SNMPv1's message encoding has no Counter64 type at all. RFC 3584, the coexistence Best Current Practice, says SMIv2 "defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1." RFC 3410 adds that MIB modules otherwise work over any protocol version, but a Counter64 object "cannot be conveyed by an engine which exclusively supports SNMPv1". ## What RFC 3584 tells a multilingual agent to do A **multilingual** agent answers SNMPv1, SNMPv2c and SNMPv3 on the same port. RFC 3584 Section 4.2.2.1 says it MUST NOT ever return a Counter64 variable binding in response to an SNMPv1 request, and that Counter64 instances are **implicitly excluded from view** for SNMPv1. Concretely: 1. **SNMPv1 `GetRequest`** naming a Counter64 instance: a `GetResponse` with error-status `noSuchName` and the error-index set to that varbind. Because an SNMPv1 response cannot carry values and an error together, the other objects in the same request come back without values as well. 2. **SNMPv1 `GetNextRequest`** landing on a Counter64 instance: the agent skips it and returns the next accessible instance that is not Counter64. If none exists, `noSuchName`. 3. **An SNMPv1 request that itself contains a Counter64 value** is ill-formed: the agent sends no response, discards it and increments `snmpInASNParseErrs`. ## What the operator sees | Poller action over SNMPv1 | Agent behaviour | What shows up on the dashboard | |---|---|---| | Walk the interface extension table | Counter64 columns skipped | 32-bit columns present, 64-bit ones simply absent; no error | | Get a named 64-bit counter | `noSuchName` for the request | "no such object" errors, often reported as a MIB problem | | Get a 64-bit counter together with other objects | `noSuchName`, no values at all | a whole batch of objects fails because of one | The walk is the dangerous case, because it fails silently: only the 32-bit columns come back, a poller that uses them may see them wrap between polls on a fast link, and nothing reports an error. ## The other directions - **Command generators.** RFC 3584 Section 4.2.1 says a manager MUST downgrade a `GetBulkRequest` to a `GetNextRequest` when it chooses SNMPv1, ignoring `non-repeaters` and `max-repetitions` and zeroing error-status and error-index. A v1 poller loses bulk retrieval too. - **Notifications.** A notification containing a Counter64 cannot be translated to SNMPv1 trap parameters, so it "will not be sent using SNMPv1" (Sections 3.2 and 4.2.3). A trap receiver still configured for SNMPv1 silently misses it. A notification configured as an inform is sent as a `Trap-PDU` when the target uses SNMPv1. - **Proxies.** A proxy forwarding an SNMPv1 manager's GetNext to a newer agent must re-send the request past every Counter64 it receives (Section 4.3.2), which RFC 3584 itself warns can be expensive. ## Why exclusion rather than translation RFC 3584 could have told agents to squeeze a 64-bit value into a 32-bit counter. It did not, because the result would be a different object wearing a familiar type: a value that wraps at a different point from the real 32-bit column and silently misleads every rate calculation built on it. Treating Counter64 as not in view keeps SNMPv1 managers consistent: they see exactly the objects SNMPv1 can describe, and the only cost is absence, which a careful operator can detect. ## Diagnosis and fix 1. Confirm the version the poller uses for that device; a version left at v1 after a template copy is a common cause. 2. Do not reload or edit MIB files: the objects exist on the agent, and the MIB on the manager only supplies names. 3. Move the poller to SNMPv2c or SNMPv3. SNMPv2c fixes the visibility but still sends a cleartext community, so this is a good moment to go straight to SNMPv3 at `authPriv`. 4. Check notification targets in the same pass, since Counter64-bearing notifications cannot reach a v1 receiver. The same rule explains a subtler symptom: a dashboard that "works" over SNMPv1 is quietly using 32-bit counters, so its utilisation numbers can be wrong on fast links without any error being raised.