SNMP Version 3

I’m involved with a large network monitoring implementation for a customer at the moment and SNMP version 3 is the primary monitoring protocol of choice. I thought I would unpack some of the concepts and configuration for SNMPv3 for your benefit. SNMPv3 is not covered in detail on the latest CCNP exams, but having a solid practical understanding of related topics is always helpful.

Most network admins and engineers are familiar with SNMPv2c which has become the dominant SNMP version of the past decade. It’s simple to configure on both the router/switch-side and just as easy on the network monitoring server. The problem of course is that the SNMP statistical payload is not encrypted and authentication is passed in cleartext. Most companies have decided that the information being transmitted isn’t valuable enough to be worth the extra effort in upgrading to SNMPv3, but I would suggest otherwise.

Like IPv4 to IPv6, there are some major changes under the hood. SNMP version 2 uses community strings (think cleartext passwords) to authenticate polling and trap delivery. SNMP version 3 moves away from the community string approach in favor of user-based authentication and view-based access control. The users are not actual local user accounts, rather they are simply a means to determine who can authenticate to the device. The view is used to define what the user account may access on the IOS device. Finally, each user is added to a group, which determines the access policy for its users. Users, groups, views.

If a group is created without a read view than all objects are available to be read by default. In contrast, if no write or notify view is defined, no objects can write or send notifications to members of the group.

Three security models can be used in SNMPv3:

  • noAuthNoPriv – requires a username, but nopassword or encryption (essentially the same as a v2 community string)
  • authNoPriv – user-based authentication only
  • authPriv – both  user-based authentication and encryption

SNMPv3 authentication uses a username/password combination that is hashed using either MD5 or SHA.

SNMPv3 encryption is performed using a symmetric key cipher like DES, 3DES, AES-128, AES-256. The cipher you choose will likely be largely dependent on the devices you plan on applying the configuration on. For example, many Cisco routers and switches support up to AES-256, but you may find that few NMS systems do.

If you are going to go through the extra effort of implementing SNMPv3, why not do both authentication and encryption? Let’s walk through a common configuration example.

SNMPv3 Polling Configuration Example

SNMPv3 Devices and Credentials
Cisco 3750 Switch:
Read-Only Group: ROGROUP
read/Write Group: RWGROUP
Write View: MYVIEWRW
Encryption Password: CANTSEEME

Let’s start by defining the two views, MYVIEWRO for read-only access and MYVIEWRW for write access.

SW1(config)#snmp-server view MYVIEWRO mib-2 included
R1(config)#snmp-server view MYVIEWRW mib-2 included

The SNMP MIB-2 management groups covers everything we would want from interfaces to system paramaters. If you wanted to exclude access to specific objects, you could add excluded statements to each view with the respective SNMP objects.

Now we need to create a read-only group and generate a user to be placed within it.

SW1(config)#snmp-server group ROGROUP v3 priv read MYVIEWRO
SW1(config)#snmp-server user USER1 ROGROUP v3 auth sha USER1PASS priv 128 CANTSEEME

SW1#show snmp group
groupname: ROGROUP security model:v3 priv
readview : MYVIEWRO writeview:
row status: active

R1#show snmp user

User name: USER1
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: AES 128
Group-name: ROGROUP

The next group will provide write access to the switch using USER2.

SW1(config)#snmp-server group RWGROUP v3 priv read MYVIEWRO write MYVIEWRW
SW1(config)#snmp-server user USER2 ROGROUP v3 auth sha USER2PASS priv 128 CANTSEEME

SW1#show snmp group
groupname: RWGROUP security model:v3 priv
readview : MYVIEWRO writeview: MYVIEWRW
row status: active

SW1#show snmp user

User name: USER2
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: AES 128
Group-name: RWGROUP

Traps and Informs

SNMP traps allow event notifications to be sent to a target device (the NMS) when an error condition occurs. This is a more proactive  response to incident management when compared to SNMP polling, which polls on a reoccurring basis, because it sends an alert immediately. Polling intervals are often five or ten minutes and may not be able to detect the that an error condition has occurred.

The inherent limitation with SNMP traps is that they are unacknowledged by the receiver. If a router sends a trap (using UPD) and the NMS never receives the notification, the router has no way to tell. Informs solve that.

SNMP informs were introduced in SNMPv2 and are available in SNMPv3 as well. They are simply traps with an acknowledgement response from the destination.

Below is a sample configuration that enables traps and informs to be sent to an NMS ( using payload encryption. Because no specific traps are included in the statements, all will be sent by default.

SW1(config)#snmp-server host version 3 priv USER1
SW1(config)#snmp-server host informs version 3 priv USER2

SNMPv3 Firewall Considerations

SNMP by default uses two ports, 161 for polling and 162 for traps. The NMS polls the router or switch using destination port UDP 161. The replies match this stateless connection, and the firewall passes it through. Traps sent from the network devices use destination port UDP 162.

Author Aaron

Aaron knows networks. He's been involved in building and supporting world-class data networks for the past 10 years - from international cloud service providers to Fortune 50 data centers. Aaron consults independently and is focused on building the best training platform available.

More posts by Aaron

Join the discussion 6 Comments

  • Mark Ellison says:

    For the most part, nicely done….


    (1) there is no such thing as ‘priv’. ‘priv’ must also be accompanied by ‘auth’. Thus: noAuthNoPriv (same as SNMPv2c) authNoPriv (hashed message, but no encryption) and authPriv (hashed message plus encryption).

    (2) you really don’t want to use informs. Informs were poorly thought out by the IETF SNMPv3 WG. In the SNMP, the ‘authoritative engine’ is the one that responds to a message. When there is no response, the ‘authoritative engine’ is the sender. This, for informs, there is extra USM security configuration to perform for each inform destination. For traps, the security configuration resides on the agent.

    For example, if there is an SNMPv3 user, ‘charles’, configured to allow get, set and notify access, you can configure trap destinations using ‘charles’ with no additional configuration. Hoever, if you want to send informs, then there needs to be configuration performed for each and every inform destination to which informs are sent using the v3User/principal ‘charles’.

    FYI, Informs were defined in SNMPv2c, but to my best recollection, never implemented.

    See IETF STD 62 for additional details.

    • aaron says:

      Great input Mark; really appreciated. I’ve removed the priv-only description from the post as I think that was never removed from an earlier draft version.

      Also good information on the adoption/implementation of informs. I had read that they went back all the way to SNMPv2, but have never seen them in live environments. I have to say that while I love that SNMPv3 allows authentication and confidentiality, vendor support is really lacking and the documentation is poor at best. It is clear why adoption has been so slow, given the barriers to implement it at scale.

  • Christy A says:

    I have a client who needs a customized SNMP course for 16-student within the next 1-2 months. Please see the requirements/course outline below and let me know if you have someone who can teach this class and have courseware (or need to develop it). I am looking for is an SME with S/W degree and that has trained at the engineering level.

    Audience: software engineers who develop SNMP agents

    When: 1-2 Months

    Where: San Jose, CA

    # of Students: 16

    Below are the details for SNMP training course:

    1. SNMPv3 Fundamentals

    2. Agent development

    a. Open source extensible agents and when one might want to use them
    b. Usage and/or development of APIs to write SNMP apps. (C, C++, perl, Java)
    c. Targeted operating system (or systems)
    d. Pre-existence of SNMP agents on those platforms
    e. Embedded platforms or not
    f. Tool cost vs. time-to-market (and market opportunity cost)
    g. Protocol validation issues

    Course Objectives:
    Watch out for common agent problems
    Make agent architectural and SDK choices
    Define agent semantics
    Coexist (if necessary) with native agents
    Be aware of important coding issues
    Describe the details of SNMP message syntax
    Fully test your agent prior to deployment
    Productize your MIB and agent products

    Proposed course outline:
    True stories of delivered agents with significant deficiencies
    Agent development steps
    Defining goals and tradeoffs
    Agent SDK selection criteria
    Agent architectural choices and issues
    Agent semantics
    Coexistence of enterprise agents with native platform agents
    Trap design
    Agent coding issues

    Data acquisition
    Read-write data management
    Returning multiple values
    Processing get-next requests
    Table index data type choices
    Multi-step “set” processing
    Code threads and uses
    Trap send logic

    Agent initialization and log files
    —SNMP message syntax and coding
    —Agent testing (static and dynamic)
    —Productizing an Enterprise MIB and agent
    Wrap-up: Course recap, Q/A, and evaluations

    Please contact me if you are interested in this opportunity.

  • Ram Ramani says:

    For the trap configuration what’s the meaning of having USER 1 in the statement. Also Traps are sent to the destination “” and you say that its encrypted, but what data encryption key will the NMS use so that it can decrypt the trap information. Are we saying that the NMS will authenticate USER 1 and use a pre-configured data encryption key to decrypt the trap

  • rama says:

    Super Ram ..!!

Leave a Reply