Configuring SNMPv3

Problem

You want to set up the router to be an SNMP agent so your network SNMPv3 NMS system can monitor it.

Solution

First, define the NMS systems that can access the router and their passwords:

	[edit snmp v3]
	aviva@router1# set 
usm local-engine user nms1 authentication-sha authentication-
	password $1991poppI
	aviva@router1# set usm local-engine user nms1 privacy-des privacy-password $1991poppI

Then, define the MIBs to which the users have access:

	[edit snmp]
	aviva@router1# set view chassis-info-only oid jnxBoxAnatomy include
	aviva@router1# set view chassis-info-only oid snmpMIBObjects include
	aviva@router1# set view chassis-info-only oid system include

You create groups and assign users to them and then define access privileges for each group:

	[edit snmp v3]
	aviva@router1# set vacm security-to-group security-model usm security-name nms1 group
	chassis-only
	aviva@router1# set vacm access group chassis-only default-context-prefix security-
	model usm security-level privacy read-view chassis-info-only
	aviva@router1# set vacm access group chassis-only default-context-prefix security-
	model usm security-level privacy notify-view chassis-info-only

 

Discussion

The basic SNMPv3 setup is similar to the SNMPv2 configuration. You define the NMS systems that can make SNMP requests to the router and which MIBs they can access. In the recipe shown here, we give access only to the objects related to the hardware chassis components.

SNMPv3 uses a USM for security, which you configure in the usm statement hierarchy. Each NMS system is a user. For each user, configure an authentication type and password to ensure that the SNMP messages come from a trusted source. Here we have configured SHA1 authentication. USM also supports MD5 authentication, which you configure with the authentication-md5 keyword.

To protect the SNMP message payload, you encrypt it, here with DES. The CLI converts both passwords into keys:

	[edit 
snmp v3 usm local-engine]
	aviva@router1# show
	user nms1 {
	 authentication-sha {
	 authentication-key "$9$5Qz6u0IrlM0OLxN-2gUjH.mTFn/CA0aZFnCtOBNdVbgoGDiPfzGU.
 5TzCAM8LXbs24aZGiM8ZUjHmPRhcyM8-ds2aZVb.
	Pf5F3SrlKLxdVYaJDKMjHqmTQreKMNds24Djq8XGDjkPfylevxN4aZqP5LxDiHqQz369CtOhclKWLz3cyrK8L
	JGUDqm"; ## SECRET-DATA
	 }
	 privacy-des {
	 privacy-key "$9$bcsYoji.zF/iHAp0OcSM8XN-w24aZGilK24ZUHk0B1ISrvWLdVYvMNbwYZG/
	CAtIEcylKvL/CKM8X-dmf5Q/COBEclK1INdVb2gTzFnApB1hleWn/8X7-wsz3n/
	0BEcyW87CtvW8xdVQF36p0ylK7dbApWLX7sYgoJZUHf5Fn9AYg5QznCAevMW7-"; ## SECRET-DATA
	 }
	}

As with SNMPv2, you create views to define which MIB branches the NMS systems can access (use the view statement at the [edit snmp] level, not at the [edit snmp v3] level). The view we configure, chassis-info-only, allows access to the Juniper Networks enterprise chassis MIB and to portions of other MIBs that retrieve chassis-related information. Because we use the notify view for the chassis-only group, we need to allow the sysUpTime object, which is part of the system OID. The notify view is used when the router sends SNMPv3 notifications (informational messages and traps) to the NMS system. We show how to configure notifications in Recipe 4.15.

Next, define the NMS system's access to the router (in the vacm statement hierarchy). SNMPv3 uses a VACM to grant access privileges to groups. You create groups that are identified by a name, then assign the desired access. A group is simply a collection of NMS systems (users) that are defined in the USM and that share the same access privileges (set in the access statement hierarchy). Here, we have a group called chassis-only that includes our NMS system nms1.

In the access commands, set the security and access privileges for the group. In our recipe, the security model is USM and the security level is privacy, which authenticates all messages and encrypts the message payload. You can also choose authentication, which provides only authentication, and none, which provides neither. The read-view and notify-view statements set the access privileges for incoming NMS requests and outgoing notifications, respectively.

To see the SNMPv3 configuration settings, use the following command:

	aviva@router1> show snmp v3
	Local engine ID: 80 00 0a 4c 01 c0 a8 47 f6
	Engine boots: 123
	Engine time: 24951 seconds
	Max msg size: 2048 bytes
	Engine ID: local
	 User Auth/Priv Storage Status
	 nms1 sha/3des nonvolatile active
	Group name Security Security Storage Status
	 model name type
	chassis-only usm nms1 nonvolatile active
	Access control:
	Group Context Security Read Write Notify
	 prefix model/level view view view
	chassis-only usm/privacy chassis-in

The JUNOS structure for configuring SNMPv3 follows the structure of the protocol specification itself. Because it is a bit complex, it's worthwhile to look at the SNMPv3 portion of the configuration file that is created by the commands in this recipe, along with some added comments.

	aviva@router1# show | except SECRET-DATA
	v3 {
	 usm { # <-- which NMS systems can access the router
	 local-engine {
	 user nms1 {
	 authentication-sha {
	 privacy-des {
	 }
	 }
	 }
	 }
	 vacm { # <-- what the NMS systems can access on the router
	 security-to-group { # <-- which access group each NMS is in
	 security-model usm {
	 security-name nms1 {
	 group chassis-only;
	 }
	 }
	 }
	 access { # <-- which MIB views the NMS systems can access
	 group chassis-only {
	 default-context-prefix {
	 security-model usm {
	 security-level privacy {
	 read-view chassis-info-only;
	 notify-view chassis-info-only;
	 }
	 }
	 }
	 }
	 }
	 }
	}
	view chassis-info-only { # <-- define a view that allows all chassis objects
	 oid jnxBoxAnatomy include;
	 oid snmpMIBObjects include;
	 oid system include;
	}