> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # SNMPv3 in Production: Users, Groups, Views, Traps, and Informs - URL: https://www.pinglabz.com/snmpv3-traps-informs/ - Published: 2026-07-12T09:34:24.000Z - Updated: 2026-08-24T09:44:13.000Z - Description: Build SNMPv3 in production form: users, groups, views, and the three security levels. The payoff is a real encrypted trap arriving and being decrypted on a Linux receiver, with no cleartext community strings on the wire. - Author: Jaime - Tags: IP Services, Network Security, Labs, CCIE, #Import 2026-08-01 19:54 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](https://www.pinglabz.com/ip-services/). ## The three security levels SNMPv3 offers three levels, and you should use the strongest: noAuthNoPriv No authentication, no encryption. A username with no security. Barely better than v2c. Do not use. authNoPriv Authentication (the message is verified as coming from a known user, unaltered) but no encryption - the data is still in cleartext. Better, but the OID values are readable. authPriv Authentication *and* privacy (encryption). The whole message is authenticated and encrypted. This is what you use. Anything less leaks data. ## 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: Trap **Fire and forget.** The router sends the notification and never checks whether it arrived. Low overhead, but a trap lost in transit is gone with no record. Inform **Acknowledged.** The receiver replies; if no acknowledgement comes, the router retransmits. Reliable, at the cost of state and retransmission traffic. ``` 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 ` and `priv aes 128 `. 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](https://www.pinglabz.com/embedded-packet-capture-ios-xe/). The full cluster index lives on the [IP services pillar](https://www.pinglabz.com/ip-services/).