CLI Operations and Configuration Examples for SNMPv3

The first task in configuring SNMPv3 is to configure the SNMP engineID. This engineID is an unambiguous identifier of an SNMP engine in the administrative domain. Consequently, it is a unique identifier of the SNMP entity, because there is a one-to-one association between SNMP engines and SNMP entities.

View-Based Access Control (RFC 3415) defines five elements:

MIB views— Identifies a set of managed objects defined in terms of a collection of subtrees, with each subtree being included in or excluded from the view.
Groups— Identifies the set of users, defined by securityModel and securityName. The access rights are the same inside the group. A user, also called a principal, belongs to only one group.
Security level— Identifies the level of security when checking access rights. The possible choices are noAuthPriv, authNoPriv, and authPriv. SNMP entities maintain authentication and privacy keys, which are generated from a user's password and the SNMP engineID. Note that noAuthPriv is not a valid level of security because the privacy key defined in SNMPv3 is linked to a user. In other words, authentication is a prerequisite for privacy to be present.
Contexts— Specified by the contextEngineID and contextName, this identifies the collection of management information accessible by an SNMP entity. Note that the default contextName is an empty string. A typical context example is a customer accessing the specific information on a provider edge router in an MPLS/VPN network. In this case, the SNMP context is attached to the customer VRF. Consequently, only SNMP operations on the VRF managed objects of the user's network are allowed.
Access policy— Access to a managed object depends on the principal (user) and the characteristics of the group it belongs to, such as the securityLevel, the securityModel, the context (if configured), the object instance, and the type of access (read, read-write).

After the SNMP engineID is configured, the order of an SNMPv3 configuration task list is groups, users, optional view(s), and optionally the host(s) where the notifications will be sent.

To enable SNMPv3 on a router, you use the following commands:

snmp-server engineID local engineID-string specifies the SNMP engine ID (a character string of up to 24 characters) on the local device. If the SNMP engine ID value is not specifically configured with this command, the SNMP entity automatically allocates a value. Because the user's authentication and privacy keys are generated from the SNMP engineID and the user itself, reconfiguring a new SNMP engineID implies that the already-configured users will not be granted access anymore. In this case, all SNMP users have to be reconfigured.
snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [read read-view] [write write-view] [notify notify-view] [access access-list] configures an SNMP group that maps SNMP users to three SNMP views—read access, write access, and notifications.
snmp-server user username group-name [remote host [udp-port port]] {v1 | v2c | v3 [encrypted] [auth {md5 | sha} auth-password]} [access access-list] [priv {des | 3des | aes {128 | 192 | 256}} privpassword] configures a new user to an SNMP group. This user can use SNMPv1, SNMPv2c, or SNMPv3. If SNMPv3 is selected, the password, which can optionally be encrypted, has to be specified for the MD5 or SHA authentication. Furthermore, SNMPv3 requires that you specify the privacy algorithm to be used (DES, 3-DES, AES, AES-192, or AES-256) and the password to be associated with this privacy protocol.
snmp-server view view-name oid-tree {included | excluded} creates or updates a view entry. The oid-tree is the object identifier of the ASN.1 subtree to be included in or excluded from the view. The oid-tree is composed of numbers such as 1.3.6.2.4 or a word such as system.

authNoPriv SNMP Example

The SNMP IOS configuration with user authentication and no encryption is straightforward:

Code View:

router(config)# snmp-server engineID local 1234567890
router(config)# snmp-server group benoitgroup v3 auth
router(config)# snmp-server user benoit benoitgroup v3 auth md5 benoitpassword
router(config)# exit

In this example, the user benoit belongs to benoitgroup, which is defined with SNMPv3 authentication. The user benoit is specified with the password benoitpassword, using the MD5 authentication algorithm.

The running configuration does not show the SNMP user-related command:

Router # show running-config | include snmp
Router # snmp-server engineID local 1234567890
Router # snmp-server group benoitgroup v3 auth

This behavior is explained in RFC 3414, which describes SNMPv3: "A user's password or non-localized key MUST NOT be stored on a managed device/node." Because the configuration file is not useful in this case, you check for configured users as follows:

Router # show snmp user
User name: benoit
Engine ID: 1234567890
storage-type: nonvolatile        active

The show snmp group command displays the names of configured SNMP groups, the security model being used, the status of the different views, and the storage type of each group:

Code View:

Router # show snmp group
groupname: ILMI                           security model:v1
readview : *ilmi                          writeview: *ilmi
notifyview: <no notifyview specified>
row status: active

groupname: ILMI                           security model:v2c
readview : *ilmi                          writeview: *ilmi
notifyview: <no notifyview specified>
row status: active

groupname: benoitgroup                    security model:v3 auth
readview : v1default                      writeview: <no writeview specified>
notifyview: <no notifyview specified>
row status: active

The first two groups, one in SNMPv1 and the second for SNMPv2c, are defined specifically for the Interim Local Management Interface (ILMI). ILMI is an ATM Forum protocol for managing ATM links. It uses SNMP to negotiate and exchange parameters across ATM links through the ATM-FORUM-MIB. The "ilmi" community string is created by default automatically and can be used for ILMI purposes only. Note that this community is for valid ILMI packets only—the ones that come in on the ILMI reserved ATM virtual circuit (0,16).

The last entry shows benoitgroup with SNMPv3 authentication configured. This group does not contain any write and notify views, and the readview is v1default. No view specified means that no access is granted. In this case, user benoit cannot set any managed objects, because the write view is not specified.

Router # show snmp view
*ilmi system - included permanent active
*ilmi atmForumUni - included permanent active
v1default iso - included volatile active
v1default internet.6.3.15 - excluded volatile active
v1default internet.6.3.16 - excluded volatile active
v1default internet.6.3.18 - excluded volatile active
v1default ciscoMgmt.252 - excluded volatile active

From the command show snmp view, you see that v1default contains every managed object below iso but excludes the SNMP User Security Model MIB (SNMP-USM-MIB, internet.6.3.15), the SNMP View-Based Access Control Model MIB (SNMP-VACM-MIB, internet.6.3.16), and the SNMP community MIB (SNMP-COMMUNITY-MIB, internet.6.3.18). Without this default read-view access, all SNMPv3 parameters could be polled—users, groups, community, etc. Access to the MIB variables describing those SNMPv3 parameters means full SNMP control over the entire network element, because the read-write community is available. Note that this default view also is applied to SNMPv1 or SNMPv2c if they are configured. Finally, the v1default view refuses access to the CISCO-TAP-MIB (ciscoMgmt.252), which is used for the cable modem intercept feature. In this case, Cisco Architecture for Lawful Intercept in IP Networks (RFC 3924) can monitor and intercept traffic from network elements. It offers service providers Lawful Intercept capabilities.

To specify a read-view access, you would enter the following:

Router(config) # snmp-server group benoitgroup v3 auth read myview
Router(config) # snmp-server view myview mib-2 included
Router(config) # snmp-server view myview cisco excluded

The show snmp view command now displays a new entry:

myview mib-2 - included nonvolatile active
myview cisco - excluded nonvolatile active

To conclude, an additional SNMPv3 show command returns the SNMP engineID:

Router # show snmp engineID
Local SNMP engineID: 1234567890
Remote Engine ID          IP-addr     Port

According to the preceding configuration, the arguments for the net-snmp utility snmpget are as follows:

Code View:

SERVER % snmpget -v 3 -u benoit -l authNoPriv -a MD5 -A benoitpassword router
  sysUpTime.0
sysUpTime = Timeticks: (840889259) 97 days, 7:48:12.59

authPriv SNMP Example

The SNMPv3 IOS configuration with user authentication and encryption is as follows:

Code View:

Router(config) # snmp-server group benoitgroup v3 auth
Router(config) # snmp-server user benoit benoitgroup v3 auth md5
  authenticationpassword md5 authenticationpassword priv des privacypassword
router(config)# exit

The configuration line with the SNMPv3 user specification does not appear in the running-config. The show snmp-server user and show snmp-server group commands return exactly the same output as in the authNoPriv example. Note, however, that the SNMP engineID is not specified from the command-line interface (CLI). Instead, it is generated from the SNMP entity:

Router # show running-config | include snmp
snmp-server group benoitgroup v3 auth
Router # show snmp user
User name: benoit
Engine ID: 80000009030000B0647AE7E0
storage-type: nonvolatile        active

According to this configuration, the arguments for the net-snmp utility snmpget are as follows:

Code View:

SERVER % snmpget -v 3 -u benoit -l authPriv -a MD5 -A authenticationpassword -X
  privacypassword router sysUpTime.0
sysUpTime = Timeticks: (61485) 0:10:14.85