Is this a Trap? SNMPv3

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:

noAuthNoPriv: requires username, but no MD5 validation of that user, and no encryption
authNoPriv: requires username, provides MD5 validation, but no encryption
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.