What did community-based SNMPv2c add over SNMPv1, and what did it leave unchanged?
answer
- same wrapper, new PDUs
- many rows per request
- notifications that get answered
- one missing object no longer fails all
- version field 0 becomes 1
basics
~10 sSNMPv2c added GetBulkRequest, InformRequest, the SNMPv2-Trap format, Counter64 and per-variable exceptions with richer error codes. It kept SNMPv1's message wrapper and cleartext community string, changing only the version field from 0 to 1.
solid answer
~50 sSNMPv2c is the SNMPv2 protocol operations (today RFC 3416) and SMIv2 (RFC 2578) carried in SNMPv1's community wrapper, as RFC 1901 defines. It added `GetBulkRequest`, which returns many table rows in one round trip; `InformRequest`, a notification the receiver answers with a `Response`; the `SNMPv2-Trap` PDU, whose first two varbinds are `sysUpTime.0` and `snmpTrapOID.0`; the `Counter64` type; and the exceptions `noSuchObject`, `noSuchInstance` and `endOfMibView`, so one missing object no longer voids a whole response. Error-status grew from six values to nineteen, from `noAccess(6)` to `inconsistentName(18)`, and row creation improved. What it did not change is security: the message is still `version`, `community`, PDU in the clear, with only the version value moving from 0 to 1. RFC 1901 is Experimental and was later declared Historic; the security SNMPv2 was meant to have arrived only with SNMPv3.
go deeper
Recall the headline: v2c brought GetBulk, Informs, 64-bit counters and better errors, but kept the same cleartext community string as v1.
Explain each addition's job: GetBulk cuts round trips, Informs are acknowledged, Counter64 suits fast counters, and exceptions let one bad varbind fail alone. Be able to name the three exception values.
Connect the additions to operations: v1-only pollers cannot see Counter64 or use GetBulk, and an Inform configured toward a v1 target becomes a trap. Know that SNMPv3 carries every one of these PDUs.
Note the status trap: v2c is an Experimental RFC later declared Historic, kept alive by deployment. Decide where its protocol features justify a version and where only SNMPv3 should carry them.
## Where SNMPv2c came from The SNMPv2 effort set out to improve both the protocol and its security. The protocol work produced SMIv2, the SNMPv2 operations, transport mappings and MIB (RFCs 1902-1907, since revised as RFC 2578-2580 and RFC 3416-3418) and a coexistence document (RFC 1908, now RFC 3584). The security work split: RFC 3410 lists the Party-based SNMPv2 (SNMPv2p), SNMPv2u and SNMPv2* as competing frameworks. **Community-based SNMPv2 (SNMPv2c)**, RFC 1901 of January 1996, "had the most support within the IETF but had no security and administration". It simply reused SNMPv1's community framework around the new PDUs. RFC 1901 is an **Experimental** RFC, and RFC 3410 records it as later declared Historic, yet it is the version most devices still speak. ## What changed in the protocol | Area | SNMPv1 (RFC 1157) | SNMPv2c (RFC 1901 + RFC 3416) | |---|---|---| | Message version field | `version-1(0)` | `version(1)` | | Bulk retrieval | none: one `GetNextRequest` step per round trip | `GetBulkRequest` (tag 5) with `non-repeaters` and `max-repetitions` | | Notifications | `Trap-PDU` (tag 4) with enterprise, agent-addr, generic-trap, specific-trap, time-stamp | `SNMPv2-Trap-PDU` (tag 7) and confirmed `InformRequest-PDU` (tag 6) | | Counters | 32-bit `Counter` | `Counter32` and `Counter64` | | Missing objects | the whole request fails with `noSuchName` | per-varbind `noSuchObject`, `noSuchInstance`, `endOfMibView` | | Error-status values | `noError(0)` to `genErr(5)` | `noError(0)` to `inconsistentName(18)` | | Response PDU | `GetResponse-PDU` | `Response-PDU` (same tag 2) | RFC 3410 summarises the gains as expanded data types (the 64-bit counter), the get-bulk operator, confirmed event notification, richer error handling, improved sets (especially row creation and deletion, via the `RowStatus` textual convention of RFC 2579) and a refined data definition language. ## Why the exceptions matter An SNMPv1 response can return either values or an error. RFC 3584 puts it plainly: an SNMPv1 Response PDU "cannot return any management information, and can only return an error-status and an error-index value" when something fails. Ask an SNMPv1 agent for twenty objects where one does not exist and the answer is `noSuchName` pointing at that one, with no data for the other nineteen. SNMPv2 marks the problem in the affected variable binding instead: - `noSuchObject`: no such object type is accessible at that name. - `noSuchInstance`: the object type exists, but not that instance. - `endOfMibView`: a `GetNextRequest` or `GetBulkRequest` ran past the last object in the view. The rest of the response still carries real values, which is what makes large polls and table walks practical. ## What stayed exactly the same - **The wrapper.** RFC 1901 takes the message form from RFC 1157 "with the exception that a new version number is used". The community is still an unencrypted octet string. - **Access control by community.** RFC 1901 reuses SNMPv1's community concept and its elements of procedure; its Security Considerations section reads, in full, "Security issues are not discussed in this memo." - **Transport.** The same UDP mapping, with requests to the agent and notifications to the receiver. - **The MIB objects.** Modules written in SMIv1 or SMIv2 work over either version, with one exception: `Counter64` cannot be carried in an SNMPv1 message. A new version number was still needed because the new PDU types and error codes would confuse an SNMPv1-only entity; RFC 1157 has an agent discard a message whose version it does not support. ## The old error codes that stayed behind RFC 3416 still lists `noSuchName(2)`, `badValue(3)` and `readOnly(4)`, each marked "for proxy compatibility". RFC 3584 Section 4.1 says SNMPv2 access to MIB data never generates them: a missing object becomes an exception, and a refused write gets a specific code such as `notWritable`, `wrongType` or `noCreation`. They survive so that a proxy can pass an SNMPv1 agent's errors upstream. Seeing `noSuchName` in a v2c response is therefore a hint that something in the path speaks SNMPv1. ## Where SNMPv3 fits SNMPv3 kept every SNMPv2 operation; STD 62 includes RFC 3416 itself. RFC 3410 describes SNMPv3 as "SNMPv2 with additional security and administration capabilities". So GetBulk, Informs, Counter64 and the exceptions are available over SNMPv2c and SNMPv3 alike. The only thing SNMPv2c gives that SNMPv3 does not is the absence of security configuration, which is exactly why it should be retired.
- Why did SNMPv2c need a new version number if its wrapper is otherwise identical to SNMPv1's?RFC 1901 says the new number was needed because of SNMPv2's new PDU types and error codes. An SNMPv1-only entity that received them under version 0 would try to parse PDUs it does not know. With version 1, RFC 1157's elements of procedure make it discard the message on the version mismatch instead, and RFC 3418 counts such messages in `snmpInBadVersions`.
- Which of these SNMPv2c additions remain in SNMPv3?All of them. SNMPv3 defines no new protocol operations: STD 62 includes RFC 3416, the SNMPv2 operations, so `GetBulkRequest`, `InformRequest`, `SNMPv2-Trap`, `Counter64` and the exceptions travel inside SNMPv3 messages unchanged. What SNMPv3 replaces is the community wrapper, with a header, a security model and view-based access control. It also gives the `Report-PDU`, whose usage RFC 3416 leaves undefined, a job.
saying these in an interview costs you the question
- SNMPv2c added encryption of the community string.
- GetBulk and Informs need SNMPv3; SNMPv2c only changed the version number.
- SNMPv2c is the IETF's Internet Standard version of SNMPv2.
- In SNMPv2c, a Get with one missing object still fails the whole response.
- endOfMibView is what an agent returns for any object it does not have.