Setting up SNMPv3 (USM)¶

SNMPv3 extends the plain community strings of SNMP v1/v2c with authentication (integrity) and encryption (confidentiality) via the User-based Security Model (USM). Vesana supports SNMPv3 per host and as a tenant-wide credential set.

Where to enter it¶

When adding a host under Credentials → SNMP: set the version to v3, the USM fields then appear.
On an existing host via Manage host → Credentials.
As a credential set of type SNMP v3 on the customer (Tenants → expand the customer → Credentials) — afterwards selectable everywhere via "Saved credentials".
In Automatic setup in the task "Resolve SNMP access" (v3: user + passwords).

Fields¶

Username (security name) — the SNMPv3 user on the device.
Auth password — for authentication.
Privacy password (priv password) — for encryption; only possible together with an auth password.
"Set protocols manually" (optional): auth protocol SHA-256, SHA-512, SHA-384, SHA-224, SHA-1 (legacy), MD5 (legacy) and privacy AES-128, AES-256, AES-192, DES (legacy). Default is "Detect automatically" — if you know the protocols, set them here.

Both passwords are stored encrypted (AES-256) and never returned in clear text. SNMPv3 passwords must be at least 8 characters long.

Security level: derived, not guessed¶

There is no security level field. Vesana derives the level from the passwords you enter:

Input	Result
username only	noAuthNoPriv
username + auth password	authNoPriv
username + auth password + privacy password	authPriv (recommended)

This applies when creating, when editing and for credential sets alike.

"Test connection"¶

SNMPv3 doesn't reveal which auth/privacy protocols a device expects. Instead of guessing: enter username and passwords and press "Test connection". Vesana tries the common combinations against the real device and stores only what demonstrably works.

The test runs directly from the server first — the answer arrives in seconds, even on a freshly installed instance without a collector. Only if the device is unreachable for the server does the host's collector take over.
Vesana first checks whether the device answers SNMP at all, then tries the whole matrix — including devices such as MikroTik that silently drop requests with the wrong protocol.
Success: "Connection established — device identifies as "switch-01"" with the detected combination (e.g. "Detected: authPriv · auth SHA256 · privacy AES"). The protocols are applied to the form and, in the host dialog, stored on the host right away ("· saved").
Failure in plain words, regardless of where the test ran:

Message	Meaning
Device does not answer SNMP	UDP 161 unreachable or SNMP disabled on the device
Username unknown on the device	the USM user doesn't exist there
Auth password does not match	authentication rejected
Privacy password does not match	priv password wrong
Device rejected the connection	the device answers but accepts no combination — check the passwords
Clock deviation from the device	USM time window violated — set the device clock
Password too short (min. 8 characters)	USM minimum length
Collector not up to date yet	the responsible collector can't run the test yet; it updates itself — name and version are in the message

Must match the device¶

Username, protocols and passwords must match the SNMPv3 user configured on the target device exactly. If anything differs, the SNMP checks return no or wrong values — so use "Test connection" before saving. When in doubt, check the SNMPv3 user configuration on the device (same auth/privacy algorithm, same passwords).

Not the same as discovery communities¶

Network search and classification in Discovery speak SNMP v1/v2c via communities. SNMPv3 credentials are used by Automatic setup when setting up devices, and they apply to the SNMP checks of the respective host.