Choosing between SNMP versions is mostly a security decision. You can use v1 or v2c on a trusted lab network, but v3 is the one that adds authentication and encryption.
This page is part of our guide to SNMP, which covers the basics of the protocol.
| Item | Value |
|---|---|
| SNMPv2c security model | Community-based |
| GetBulk operation | Introduced in SNMPv2, as an extension of GetNext |
| 64-bit counters | Counter64 type added in SNMPv2 |
| SNMPv3 security model | User-based Security Model (USM) |
| Authentication protocols in RFC 3414 | HMAC-MD5-96 and HMAC-SHA-96 |
| Privacy protocol in RFC 3414 | CBC-DES, which uses 56-bit keys |
These figures come from An Introduction to Computer Networks and RFC 3414. Standards and recommendations can change, so check the sources before you rely on them.
How the three versions differ at a glance
All three versions let a manager read and set values that an agent exposes as objects, each named by an SNMP OID. What changes between versions is the data types, the operations and, above all, how a request is secured.
- SNMPv1: the original. It has Get, GetNext and Set, and it uses a shared community name as a password.
- SNMPv2c: adds GetBulk, 64-bit counters and richer error reporting, but keeps the community model.
- SNMPv3: keeps the v2c operations and adds user-based authentication and optional encryption.
The practical consequence is that the version is a property of each request. A manager chooses it per device, so one monitoring system can poll old and new equipment side by side.
SNMPv1 and its limits
SNMPv1 is the oldest version and is still found on old switches, printers and embedded devices. Access is controlled by a SNMP community string, a shared text value sent with each request.
It has no concept of a user. Anyone who learns the community string has whatever access that string grants, and nothing in the message is encrypted.
Its counter type is the plain Counter, which wraps around when it reaches its maximum. On a fast interface that makes traffic graphs unreliable unless you poll often.
The v1 Get behaviour is also blunt. According to the textbook, “When an SNMPv1 agent receives a list of OIDs as part of a Get() request, and one or more of them is unavailable, then an error is returned” (Introduction to Computer Networks). One missing object can therefore spoil an entire request.
What SNMPv2c adds
SNMPv2 introduced several evolutionary changes. The source describes them as changes “to the SMI, to various MIBs, and to the basic protocol operation.”
The data types were updated: SNMPv2 introduced Counter32, Gauge32 and the 64-bit Counter64.
The same source says SNMPv2 introduced GetBulk as an extension of GetNext. It lets a manager pull many table rows in one request instead of walking one object at a time.
The Get behaviour was softened too. For OIDs the agent cannot answer, the special value noSuchInstance or noSuchObject is substituted, so the rest of the request still succeeds.
The “c” stands for community. The textbook notes that “Eventually most of the SNMP community settled on SNMPv2 c, the version of SNMPv2 that stayed with the community-based security model.” An earlier SNMPv2 proposal for improved security “was not widely adopted”.
That means v2c has the same weakness as v1: no per-user identity and no encryption. The source also says essentially all SNMPv2 agents also support SNMPv1 queries, and answer according to the version of the request received.
What SNMPv3 changes
The textbook summarises it this way: “SNMP version 3 added authentication and encryption to SNMPv2c, but made relatively few other changes except to nomenclature.” The new model is the User-based Security Model (USM), which supports unauthenticated, authenticated, and authenticated-and-encrypted operation; choose authPriv for both authentication and encryption.
RFC 3414 describes the use of HMAC-MD5-96 and HMAC-SHA-96 as the authentication protocols and the use of CBC-DES as the privacy protocol. The same RFC says these can be replaced or supplemented in the future, so newer devices often offer stronger options.
The textbook notes that DES uses 56-bit keys, which is a good reason to check which algorithms your devices actually offer.
The textbook explains that SNMPv3 defines separate levels of security: authentication-only, which addresses modification, masquerade and replay, and encryption, which also addresses disclosure. Tools usually name three levels.
- noAuthNoPriv: a user name only, with no protection.
- authNoPriv: messages are authenticated but readable.
- authPriv: messages are authenticated and encrypted.
The encryption uses shared secret keys. As the source puts it, “public-key encryption is not used”, so the manager and agent must both be configured with the same credentials.
Which version should you pick?
Choose the newest version that both your devices and your monitoring tool support. Prefer v3 with authentication and privacy for anything reachable beyond a closed management network.
- Use v3 authPriv where devices support it.
- Fall back to v2c for polling busy interfaces on trusted segments, so you get 64-bit counters and GetBulk.
- Avoid v1 unless a device offers nothing else.
- If you must use community strings, change the defaults and limit which hosts may query.
Moving to v3 costs more setup: you create users, choose algorithms and store keys on both sides. That effort is the price of having per-user identity and protected messages, and it is usually worth it on production networks.
Checking versions on your own devices
Before you change anything, find out what each device already supports. Most agents expose their version settings in the same place as their community strings or user accounts, so look there first.
- List your devices and note the oldest firmware or the oldest model in each group.
- Check whether each one offers v3 users, and which authentication and privacy algorithms it lists.
- Test a read-only poll with the newest version the device accepts.
- Compare the results with your old polling, especially counters on busy interfaces.
- Switch the monitoring tool over one device group at a time, and keep the old settings until the new ones are proven.
Because agents answer according to the version of each request, you can test v3 without breaking an existing v2c poller. Run both for a while, then retire the older one once the data matches.
When a poll fails after a version change, the cause is usually a mismatch rather than a fault. Typical culprits are a wrong user name, a different authentication algorithm on each side, or a privacy passphrase that does not match.
Keep your credentials out of shared documents and rotate them if staff who knew them leave. A strong v3 setup is only as good as the secrecy of its keys.
Frequently asked questions
Is SNMPv2c secure?
Show answer
No. It keeps the community-based model, so there is no per-user authentication or encryption.
Does SNMPv3 replace v2c operations?
Show answer
No. v3 added authentication and encryption to v2c with few other changes, so you still use the same kinds of requests.
Why use v2c at all?
Show answer
It is simple to set up and supports GetBulk and 64-bit counters. It suits trusted networks where v3 is not available.
Can v1 read 64-bit counters?
Show answer
No. Counter64 was added with SNMPv2, so v1 has only the original Counter type.
