Mar
22

One of our students asked me for a concise example of SNMPv3. James, here you go!  This blog has examples and explanations of the features used in SNMPv3.
Older versions of SNMP didn’t provide all the features of SNMPv3. V3 supports a User-based Security Model (USM) for authentication, and a View-based Access Control Model (VACM) to control what that user account may access.  Of course the user accounts don’t represent end users, they are just the configuration elements we configure on the SNMP devices, primarily for creating the connection to or from the SNMP device.

With version 3 we may use the following methods:

  1. noAuthNoPriv: requires username, but no MD5 validation of that user, and no encryption
  2. authNoPriv: requires username, provides MD5 validation, but no encryption
  3. authPriv: You guessed it. Requires username, uses MD5 validation, and encrypts too.

Let’s configure the router to support a SNMPv3 manager who will be communicating with it. First, we assign an engineID. This is optional, as the router would have automatically assigned one, but helpful due to the fact that we may need to configure the engineID on the remote manager and by hard coding it on the router we will know what the value is beforehand. (Note: the 00 in food, are Zero Zero, as the engineID is in hexadecimal. :) )

R1(config)#snmp-server engineID local badf00dbabe

Next we can define a view that specifies what may be managed (VACM, see above). In this example, the two views refer to mib-2 and Cisco object IDs respectively.

R1(config)#snmp-server view MYVIEW mib-2 included
R1(config)#snmp-server view MYVIEWRW cisco included

So far, these views are not worth much, as they are just sitting in the config, and not being called on. We can verify the views exist, and also see the other default views present on the router.

R1#show snmp view
*ilmi system - included permanent active
*ilmi atmForumUni - included permanent active
MYVIEW mib-2 - included nonvolatile active
MYVIEWRW cisco - included nonvolatile active
v1default iso - included permanent active
v1default internet.6.3.15 - excluded permanent active
v1default internet.6.3.16 - excluded permanent active
v1default internet.6.3.18 - excluded permanent active
v1default ciscoMgmt.394 - excluded permanent active
v1default ciscoMgmt.395 - excluded permanent active
v1default ciscoMgmt.399 - excluded permanent active
v1default ciscoMgmt.400 - excluded permanent active

Let’s set up some groups and users, so that a remote SNMP manager may get information from this router and/or configure via SNMP. We have options. If we want to allow the manager station to request data, but not require a MD5 hash validation of the user, nor require encryption for the SNMP traffic, we could create a group that doesn’t require MD5 authentication nor encryption. The group and user that we might put in this group may look like this:

R1(config)#snmp-server group groupone v3 noauth read MYVIEW
R1(config)#snmp-server user keith groupone v3
Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...

Note, this would not be much better than SNMPv1, with simple plain text passwords. To verify the group and user, we can use a few simple show commands.

R1#show snmp group
groupname: ILMI                             security model:v1
readview : *ilmi                            writeview: *ilmi
notifyview:
row status: active

groupname: ILMI                             security model:v2c
readview : *ilmi                            writeview: *ilmi
notifyview:
row status: active

groupname: groupone                         security model:v3 noauth
readview : MYVIEW                           writeview:
notifyview:
row status: active

R1#show snmp user

User name: keith
Engine ID: BADF00DBAB0E
storage-type: nonvolatile        active
Authentication Protocol: None
Privacy Protocol: None
Group-name: groupone

Next, we create another group, still with NO authentication or encryption, but we will add the ability to write via SNMP based on the view named MYVIEWRW.

R1(config)#snmp-server group grouptwo v3 noauth read MYVIEW write MYVIEWRW
R1(config)#snmp-server user anthony grouptwo v3

Notice, the show group and user commands include both users and groups. Grouptwo has a writeview specified, just as we configured it.

R1#show snmp group
<snip>
groupname: groupone                         security model:v3 noauth
readview : MYVIEW                           writeview:
notifyview:
row status: active

groupname: grouptwo                         security model:v3 noauth
readview : MYVIEW                           writeview: MYVIEWRW
notifyview:
row status: active

R1#show snmp user
<snip>
User name: anthony
Engine ID: BADF00DBAB0E
storage-type: nonvolatile        active
Authentication Protocol: None Privacy Protocol: None
Group-name: grouptwo

Now, lets add some MD5 authentication . No encryption yet, but we are making progress over groupone and grouptwo.

R1(config)#snmp-server group groupthree v3 auth read MYVIEW
R1(config)#snmp-server user marvin groupthree v3 auth md5 marvin-passwd

Notice in the show command, that the new group includes “auth”. We are beginning to use the features that makes SNMPv3 desireable.

R1#show snmp group

groupname: groupone                         security model:v3 noauth
readview : MYVIEW                           writeview:
notifyview:
row status: active

groupname: grouptwo                         security model:v3 noauth
readview : MYVIEW                           writeview: MYVIEWRW
notifyview:
row status: active

groupname: groupthree security model:v3 auth
readview : MYVIEW                           writeview:
notifyview:
row status: active

R1#show snmp user
<snip>
User name: marvin
Engine ID: BADF00DBAB0E
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: None
Group-name: groupthree

R1#

Now, we will add a group and user, that leverages the authentication and encryption.

R1(config)#snmp-server group groupfour v3 priv read MYVIEW
R1(config)#snmp-server user scott groupfour v3 auth md5 scott-passwd priv des crypt-key

R1#show snmp group
groupname: groupfour security model:v3 priv
readview : MYVIEW                           writeview:
notifyview:
row status: active

R1#show snmp user 

User name: scott
Engine ID: BADF00DBAB0E
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: DES
Group-name: groupfour

R1#

Our final group and user will use authentication and encryption, along with the ability to write to the SNMP device based on the view MYVIEWRW. This is the most secure of all the examples shown here.

R1(config)#snmp-server group groupfive v3 priv read MYVIEW write MYVIEWRW
R1(config)#snmp-server user petr groupfive v3 auth md5 peter-passwd priv 3des crypt-key

R1#show snmp group
<snip>
groupname: groupfive                        security model:v3 priv
readview : MYVIEW writeview: MYVIEWRW
notifyview:
row status: active

R1#show snmp user 

User name: petr
Engine ID: BADF00DBAB0E
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: 3DES
Group-name: groupfive

R1#

SNMPv3 has the ability to communicate via TRAPs and INFORMs. A TRAP is an SNMP message sent from one application to another, probably the manager station. Unfortunately, TRAPs are not acknowledged so the router doesn’t know if the remote device received it. SNMPv2 and v3 may use an INFORM, which is nothing more than an acknowledged TRAP.

To set up traps and informs, we can use the syntax below. Note that the traps are being sent using an account that doesn’t use MD5 authentication, or encryption, based on the user account configured to send it. The inform destination is using an account that uses authentication, but not encryption. A better use would be to include authentication and encryption, using an account that is assigned to groupfive. The SNMP manager would need to be properly configured with the correct user account information to receive these traps and inform PDUs. The parameters at the end of the command indicate what will trigger the traps/informs.

R1(config)#snmp-server host 10.0.0.100 version 3 noauth keith snmp ipsla hsrp cpu
R1(config)#snmp-server host 10.0.0.100 informs version 3 auth marvin cpu syslog

Note:  Any names used in the demonstration are purely intentional.   Thanks to some of my fellow CCIE comrades, namely Anthony, Marvin, Scott and Petr.

Thanks again James for your request, and best wishes to all in your studies.

 


You can leave a response, or trackback from your own site.

9 Responses to “Is this a Trap? SNMPv3”

 
  1. jkdrouter says:

    Lot’s of good stuff lately Mr. Barker – thanks for taking the time.

  2. TacACK says:

    The WORD on SNMP V3 :) Thanks.

  3. AJN says:

    Brief and clear, thank you!

  4. Seifeddine says:

    Thanks a lot :) really appreciate especially if you could dig deeper into the priv community :) and what is the difference between the regular one :)

    Really appreciate it

    Thanks

  5. Ronald says:

    I lately tried to get SNMPv3 working on a HP ProCurve 3400cl switch, but without any luck. Today I received some 5400zl switches and will try again to get it working. Much of these procedures on e.g. Cisco switches are comparable with HP CLI configuration. I will use this guide to gather some thoughts if it might not be working.

    Cheers,
    Ronald.

  6. Rachid Chaoua says:

    Excellent resource. This is the most clear and concise SNMPv3 reference I have found thus far on the www. Of course this is after I configured it in my environment!!

  7. Paul Gilbert says:

    Great explanation. Glad to be able to get this from you.

  8. Istvan Segyik says:

    Badfoodbabe :) ))

  9. a7ndrew says:

    Hi, thanks for the great tutorial.
    Just one question, after you’ve entered the snmp-server user command is there any way to view the passwords and encryption keys you have entered? It doesn’t seem to appear on running configurations or the sh snmp user command.

 

Leave a Reply

Categories

CCIE Bloggers