SNMPv3 in Production: Users, Groups, Views, Traps, and Informs

SNMPv1 and v2c send everything - including your community string, which is effectively a password - in cleartext across the network. Anyone with a packet capture has your read (or write) access. SNMPv3 fixes this with real authentication and encryption, but it does so through a configuration model of users, groups, and views that is genuinely more involved than "snmp-server community public RO". The extra effort is the price of not broadcasting your monitoring credentials.

This article builds SNMPv3 in production form and - the payoff - shows a real encrypted trap arriving and being decrypted on a Linux receiver. For the fundamentals, see the IP services pillar.

The three security levels

SNMPv3 offers three levels, and you should use the strongest:

The configuration model: view, group, user

SNMPv3 is built bottom-up from three objects, and understanding the layering is understanding the config:

1. A view defines what OIDs can be accessed - a subtree of the MIB tree, included or excluded.
2. A group ties a security level to a view - "users at this level can read this view".
3. A user belongs to a group and carries the actual credentials (auth password, priv password).

! 1. The view - what OIDs are visible
snmp-server view PLVIEW iso included
snmp-server view PLVIEW internet included

! 2. The group - security level + view
snmp-server group PLGRP v3 priv read PLVIEW

! 3. The user - credentials, member of the group
snmp-server user pladmin PLGRP v3 auth sha PlAuthPass123 priv aes 128 PlPrivPass123

Read that user line carefully - it is the crux. auth sha PlAuthPass123 sets the authentication (SHA, with its password); priv aes 128 PlPrivPass123 sets the encryption (AES-128, with its password). Two separate secrets, two separate purposes. Use SHA for auth (not MD5, which is deprecated) and AES for privacy (not DES, which is broken).

Verification, on the router

R1#show snmp user
User name: pladmin
Engine ID: 800000090300AABBCC005F00
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: PLGRP

R1#show snmp group
groupname: PLGRP    security model:v3 priv
readview : PLVIEW   notifyview: *tv.FFFFFFFF...

R1#show snmp view | include PLVIEW
PLVIEW iso - included nonvolatile active
PLVIEW internet - included nonvolatile active

Note the Engine ID in show snmp user - 800000090300AABBCC005F00. Remember it, because it is the single most important value when you configure the trap receiver, and the thing people forget.

Views: why you restrict what is visible

A view is a security control. A monitoring user should be able to read the interface and system MIBs but not, say, the running configuration or sensitive tables. By building a view that includes only what the user needs, you limit the blast radius if the credentials leak.

! A restrictive view - allow the standard MIBs, deny a sensitive subtree
snmp-server view LIMITED internet included
snmp-server view LIMITED 1.3.6.1.4.1.9.9.99 excluded    ! exclude a specific Cisco subtree

The default deny is implicit: anything not explicitly included in the view is invisible. This is exactly the discipline you want - grant the minimum, and a compromised monitoring account cannot walk your entire MIB tree.

Traps vs informs: the reliability difference

Both send an event notification to a receiver. The difference is acknowledgement:

snmp-server enable traps
snmp-server host 192.168.99.100 version 3 priv pladmin udp-port 10162          ! trap
snmp-server host 192.168.99.100 informs version 3 priv pladmin udp-port 10162  ! inform

show snmp host confirms both:

R1#show snmp host
Notification host: 192.168.99.100  udp-port: 10162  type: inform  user: pladmin  security model: v3 priv
Notification host: 192.168.99.100  udp-port: 10162  type: trap    user: pladmin  security model: v3 priv

Use informs for events you cannot afford to lose - a link failure, an environmental alarm, anything that drives an operational response. Use traps for high-volume, less-critical telemetry where the occasional loss does not matter. The reliability of informs costs the router memory (it holds the state until acknowledged) and generates retransmissions, so it is a deliberate trade, not a default-everything choice.

The payoff: a real encrypted trap, decrypted on Linux

Configuration is one thing; proving the encryption works end to end is another. On a Linux trap receiver (net-snmp snmptrapd), the SNMPv3 user must be recreated with the router's engine ID - this is the step everyone misses:

# /etc/snmp/snmptrapd.conf
createUser -e 0x800000090300AABBCC005F00 pladmin SHA "PlAuthPass123" AES "PlPrivPass123"
authUser log,execute,net pladmin priv

The -e 0x800000090300AABBCC005F00 is the router's engine ID from show snmp user. Without the matching engine ID, the receiver cannot verify the authentication and the trap is dropped as unauthenticated. This is the number-one reason "my SNMPv3 traps are not arriving" - the config is fine, but the engine IDs do not match.

Trigger an event (a loopback flap generates a linkUp), and the receiver logs the fully-decrypted trap:

2026-07-12 02:25:52 [UDP: [192.168.99.1]:59301->[192.168.99.100]:10162]:
SNMPv2-MIB::sysUpTime.0 = Timeticks: (72360) 0:12:03.60
SNMPv2-MIB::snmpTrapOID.0 = OID: IF-MIB::linkUp
IF-MIB::ifIndex.7 = INTEGER: 7
IF-MIB::ifDescr.7 = STRING: Loopback99
IF-MIB::ifType.7 = INTEGER: softwareLoopback(24)
enterprises.9.2.2.1.1.20.7 = STRING: "up"

That output is the whole point: a message that crossed the network authenticated with SHA and encrypted with AES-128, arriving intact and readable only because the receiver held the right credentials and the matching engine ID. A packet capture of that same trap on the wire would show ciphertext. That is SNMPv3 authPriv working - and it is the difference between monitoring you can trust and monitoring that leaks.

Deployment notes

• Engine ID matching is everything for informs and remote users. The receiver's createUser (or equivalent) must use the router's engine ID. Mismatch = silent drop.
• Port 162 is the default, but it is often already bound (by an existing NMS or a system socket). The lab used udp-port 10162 to avoid a conflict - a real-world nuisance worth knowing. Match the port on both ends.
• SHA + AES, never MD5 + DES. The old algorithms are deprecated or broken. If your gear or NMS only supports MD5/DES, that is a reason to upgrade, not a reason to use them.
• Restrict the view. A monitoring user does not need write access or the whole MIB tree.

Key takeaways

• SNMPv3 replaces v2c's cleartext community strings with real authentication and encryption. Use authPriv - anything less leaks data.
• The model is layered: a view (which OIDs) is tied to a group (security level), which a user (credentials) belongs to.
• The user carries two secrets: auth sha <pass> and priv aes 128 <pass>. Use SHA and AES, not MD5 and DES.
• Restrict the view to the minimum OIDs a monitoring user needs - the default deny limits the damage if credentials leak.
• Traps are fire-and-forget; informs are acknowledged and retransmitted. Use informs for events you cannot afford to lose.
• We proved it end to end: a SHA-authenticated, AES-128-encrypted trap decrypted on a Linux receiver. The receiver's user must be created with the router's engine ID - the step everyone forgets, and the number-one cause of "my traps are not arriving".

Next: Embedded Packet Capture - Wireshark inside your router. The full cluster index lives on the IP services pillar.