SNMPv3 Configuration on Cisco IOS and Junos: authPriv Setup

SNMPv1/v2c community strings cross the network in plaintext, which is why monitoring credentials on production gear should use SNMPv3 with authPriv - SHA authentication plus AES encryption. The catch is that SNMPv3's user/group/VACM model differs sharply between vendors: Cisco IOS collapses it into three global commands, while Junos splits users (USM) from access rights (VACM). This guide shows both, step by step, with the exact commands and an snmpwalk verification for each.

Why SNMPv1/v2c Still Fails Compliance

An SNMPv2c community is a shared password sent in clear text with every poll and every trap. Anyone on the management path who can run a packet capture recovers it in seconds, and a community string of public is discovered by scanning tools within minutes of a device being exposed. There is no per-user accounting, no integrity check, and no replay protection: an attacker who captures a legitimate poll can replay it or forge a response, and nothing in the protocol notices.

SNMPv3 fixes this with three independent mechanisms, and it is worth being precise about which does what because the configuration mistakes cluster around exactly this distinction:

• Authentication (SHA-1, SHA-224/256/384/512) proves the message came from someone holding the key and that it was not altered in transit.
• Privacy (AES-128/192/256, or legacy DES) encrypts the payload so an observer cannot read OID values or community-equivalent data.
• The User-based Security Model (USM) - not an algorithm but the framework that binds a username to those keys, plus the engine ID and boot counters that make the protocol replay-resistant.

Access control is a separate layer entirely: the View-based Access Control Model (VACM) decides which OIDs a given (user, security level, context) triple may read or write. You can configure USM perfectly and still have snmpwalk return nothing, because VACM - not USM - is what authorises the request.

SNMPv3 Security Levels

• noAuthNoPriv - username only, no password, no encryption.
• authNoPriv - MD5/SHA authentication, no encryption.
• authPriv - SHA/MD5 authentication plus AES/DES payload encryption. Use this for production monitoring.

Each level is a strict superset of the one below, and a device will only answer a request whose level the user and the VACM group both permit. If the NMS polls at authPriv but the group was granted only auth access, the device discards the PDU silently - no error is logged by default, which is why "the walk returns nothing" is the single most common SNMPv3 symptom.

SNMPv3 on Cisco IOS / IOS-XE

Cisco's model: a group defines the security level and view, then a user is bound to the group with auth and privacy keys:

snmp-server view RESTRICTED iso included
snmp-server group ADMIN v3 priv read RESTRICTED
snmp-server user mon-user ADMIN v3 auth sha AuthPass123! priv aes 128 PrivPass123!

Breakdown: the group ADMIN uses SNMPv3 at priv level with read access to view RESTRICTED (the whole iso tree). The user mon-user authenticates with SHA and encrypts with AES-128. Verify with:

show snmp user
show snmp group

A few IOS-specific details that trip people up. Newer IOS-XE releases add snmp-server group ADMIN v3 auth as a fourth level keyword, but omitting it defaults the group to noauth - which will then reject your authPriv user. If the platform supports stronger authentication, prefer it explicitly:

snmp-server user mon-user ADMIN v3 auth sha-256 AuthPass123! priv aes 256 PrivPass123!

To scope monitoring to a specific MIB subtree rather than all of iso, build a tighter view and, better still, exclude the writable and sensitive branches:

snmp-server view IFACE ifEntry included
snmp-server view IFACE iso excluded
snmp-server view IFACE system included
snmp-server group ADMIN v3 priv read IFACE
snmp-server group ADMIN v3 priv context vlan-1 read IFACE

ACL the SNMP service itself so only the NMS may poll, and restrict traps from the device's own CLI as described in the logging articles linked at the end:

access-list 20 permit 192.0.2.50
snmp-server community DISABLED ro 20
snmp-server host 192.0.2.50 version 3 priv mon-user
snmp-server enable traps

SNMPv3 on Juniper Junos

Junos separates the pieces explicitly: a view of OIDs, a USM user with auth/priv passwords, a security-to-group mapping, and VACM access entries granting the group read access to the view at a security level:

set snmp view TESTSNMP3VIEW oid .1 include
set snmp v3 usm local-engine user mon-user authentication-sha authentication-password AuthPass123!
set snmp v3 usm local-engine user mon-user privacy-aes128 privacy-password PrivPass123!
set snmp v3 vacm security-to-group security-model usm security-name mon-user group mon-grp
set snmp v3 vacm access group mon-grp default-context-prefix security-model any security-level authentication read-view TESTSNMP3VIEW
set snmp v3 vacm access group mon-grp default-context-prefix security-model any security-level privacy read-view TESTSNMP3VIEW

Two notes from real deployments: if the device uses a non-default routing-instance, duplicate the VACM access lines with that instance as the context-prefix (and add set snmp routing-instance-access). And after configuration, confirm with show snmp v3.

The two VACM access lines are not redundant. The security-level authentication entry covers authNoPriv requests and the security-level privacy entry covers authPriv; Junos does not infer one from the other, so a policy that grants only privacy will reject an NMS that falls back to authNoPriv when it cannot negotiate encryption. Grant both unless you have a reason not to, and prefer security-model usm over any once you have confirmed the configuration works - it narrows the surface.

Useful verification on Junos:

show snmp v3
show snmp v3 usm user
show snmp v3 vacm access
show configuration snmp | display set

Junos also lets you scope SNMP to a logical system and restrict source addresses with a firewall filter; both are worth doing on a router with an out-of-band management network, because SNMPv3 encryption protects the payload but does nothing to stop a flood of polls from an unauthorised host.

Verifying from the NMS Side

snmpwalk -v3 -u mon-user -l authPriv -a SHA -A 'AuthPass123!'          -x AES -X 'PrivPass123!' 192.0.2.10 SNMPv2-MIB::sysDescr

A successful walk returning sysDescr proves user, group, view, auth and privacy are all consistent. Common failures: password length/minimum-entropy policies (use 8+ character secrets), a view that excludes the OIDs the NMS polls, and forgetting that SNMPv3 user changes on Junos need a commit to take effect.

Read the failure sign carefully, because snmpwalk's errors map onto specific layers of the model:

• Timeout: No Response - usually a mismatch in level or a USM engine-ID problem: the user's local-engine entry does not match the engine the NMS authenticated against. On Junos this happens when the local engine ID changed (a device re-image or a reboot with a different engine), invalidating every configured user's key material. Re-enter the passwords to re-key.
• Authentication failure (incorrect password, community or key) - the auth password on the NMS differs from the device, or the NMS is using a different auth protocol (SHA vs SHA-256). Both sides must agree exactly.
• Reason: authorizationError (access denied to that object) - USM and authentication succeeded, so the problem is purely VACM: the view does not include the OID, or the group has no access entry at the required security level.
• Walk returns only sysDescr and then dies - the view includes system but excludes iso, so the walk stops where the authorisation does. That is the view working as designed, not a bug.

Because SNMPv3 hides the payload, packet captures on the NMS side show nothing useful about the failure beyond the PDU type. When debugging, temporarily add a second test user at a lower level from a lab host, then remove it - engineering around the protocol's opacity by opening it briefly is faster than guessing.

Engine ID, Discovery and Why Users Suddenly Stop Working

Every SNMPv3 agent has an engineID - a unique identifier that, combined with a boot counter and a per-user boot count, defeats replay attacks and (in some implementations) acts as a key salt. When an NMS first talks to an agent it performs discovery: it sends a request with an empty engine ID, the agent replies with its own, and the NMS derives the localised keys from the user's passphrase. This is why a user that worked for months can break after a device reload or a firmware upgrade: if the engine ID is regenerated, every previously localised key is invalid and re-authentication fails until the NMS rediscovers the new engine and re-localises.

You can see and pin the engine ID on both platforms:

# Cisco IOS / IOS-XE
show snmp engineID
snmp-server engineID local 8000000903000C68E2F50000
# Junos
show snmp engine-id
set snmp engine-id local 8000000903000c68e2f50000

Setting it explicitly is a good idea on gear that will be measured by a long-lived monitoring platform: it removes the surprise. On the NMS side, tools such as Zabbix, LibreNMS and Observium cache the discovered engine and localised keys, so after a re-image you may need to clear that cache or re-enter the credentials.

Traps and Informs over SNMPv3

Polling is half the story; unsolicited notifications are the other half, and they need their own configuration because a trap travels in the opposite direction and still has to be authenticated and encrypted.

# Cisco IOS: send v3 traps to the NMS using an existing user
snmp-server host 192.0.2.50 version 3 priv mon-user
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps bgp

# Junos: define the target, then supply the USM credentials
set snmp v3 target-address nms-trap-addr address 192.0.2.50
set snmp v3 target-address nms-trap-addr port 162
set snmp v3 target-parameters nms-trap-params parameters message-processing-model v3
set snmp v3 target-parameters nms-trap-params parameters security-model usm
set snmp v3 target-parameters nms-trap-params parameters security-level privacy
set snmp v3 target-parameters nms-trap-params parameters security-name mon-user
set snmp v3 notify nms-notify type trap
set snmp v3 notify nms-notify tag nms-trap-tag
set snmp v3 notify-filter nms-notify-oid oid .1 include
set snmp v3 target-address nms-trap-addr tag-list nms-trap-tag

Prefer informs over traps where the platform supports them: an inform is acknowledged, so the sender retries when the receiver is down, whereas a trap is fire-and-forget and is silently lost during a network event - exactly when you need it most. The trade-off is that the agent now holds state for outstanding confirms, which costs a little CPU on a busy router.

Choosing Authentication and Privacy Protocols

Cisco and Juniper both support the original SHA-1/DES combination for backward compatibility, and neither should be used on new deployments. The roadmap is straightforward:

• Authentication: use SHA-256 at minimum; SHA-512 where both ends support it. MD5 and SHA-1 are considered weak and may be rejected outright by modern management platforms.
• Privacy: AES-128 is the safe baseline; AES-256 is current best practice on hardware that supports it (and on Cisco, AES-256 requires the relevant cryptographic image/feature set).
• Never mix vendors' shorthand: "SHA" on one platform and "SHA-1" on another are the same thing, but some tools list only the newer names. Confirm both ends use the identical algorithm string before blaming the device.

One final operational note on passwords: the standard requires authentication passphrases of at least eight octets, and privacy passphrases of at least eight as well. Using the same string for both functions is tempting and works, but it halves the effective entropy of the pair - use two distinct secrets, stored in the monitoring platform's vault rather than in a shared spreadsheet.

Hardening Notes

Restrict the NMS source addresses even with v3 (an ACL on the SNMP service), disable v1/v2c where possible, and keep SNMPv3 users separate from login accounts. For the wider AAA picture on Cisco gear see our RADIUS vs TACACS+ guide, and if the management platform still cannot poll, work through the step-by-step SNMP troubleshooting flow in our 华为 CE 交换机 SNMP 网管不通排查 article (the methodology applies to any vendor). For the engine-ID and discovery details that explain many of the failures above - and for a second vendor's exact syntax - see our SNMPv3 security levels and engine-ID verification write-up and the Dell OS10 SNMPv3 configuration example, which uses the same USM/VACM vocabulary with different defaults. Whichever platform you are polling, the SNMP inventory is usually the first data source you wire into Zabbix SNMP monitoring, so get the credentials right before the templates.

原文链接：https://icookservers.blog/2023/02/13/setting-up-snmpv3-on-cisco-ios-and-juniper-junos