O'Reilly logo

JUNOS Cookbook by Aviva Garrett

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. SNMP

Introduction

The Simple Network Management Protocol ( SNMP) is an Internet standard protocol for remotely managing routers, switches, servers, workstations, and other devices on an IP network. SNMP was first introduced in the late 1980s and is now widely supported. The first version of SNMP, Version 1 (SNMPv1; RFC 1157), defines the architecture and framework for SNMP.

SNMP Version 2 (SNMPv2) was proposed in 1993 to improve performance, manager-to-manager communications, and security. It was defined in RFCs 1155 and 1213. However, SNMPv2 was not widely accepted because the IETF did not reach consensus on the security features. A revised version, referred to as Community SNMPv2, or SNMPv2c, was later approved by the IETF ( RFCs 1902 and 3416). This version contains all the proposed SNMPv2 enhancements except for the security features, including more detailed error codes, addition of the GetBulk operation for more efficient retrieval of large amounts of data, and support for 64-bit counters. For security, this version supports community strings, which act as text-based passwords for determining how SNMP managers can access the data on SNMP agents. SNMPv2 is currently the most commonly deployed version of SNMP.

The newest version, SNMP Version 3 (SNMPv3), introduced in 1999 ( RFCs 3410 through 3418), defines stronger security features, including authentication for accessing network devices and encryption of SNMP packets. SNMPv3 uses a user-based security model (USM) for authentication, data integrity, message replay protection, and protection of the message payload, and a view-based access control model (VACM) to define access to the management information. SNMPv3 is currently not used much because it is fairly new and only a few network device manufacturers and network management system (NMS) vendors support it.

SNMP uses UDP port 161, and SNMP traps use UDP port 162.

The JUNOS software supports SNMP Versions 1, 2c, and 3.

This chapter discusses how to configure the SNMP agent on the router with SNMPv2 and SNMPv3 and illustrates some basic techniques for using SNMP to query the router to collect information. Much of the information gathering done by SNMP is done from the NMS system, either with GUI or CLI tools. Discussion of the workings of the NMS systems is beyond the scope of this book; you should refer to your NMS documentation. For more information about SNMP see SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 (Addison-Wesley).

SNMP Management Model

SNMP uses a client—server model. The SNMP client is called a manager, and the server is called an agent. The managers are centralized systems on the network that actively monitor the agents, which are the actual network devices, by querying and collecting status and statistics information from them. Managers can run on PCs or workstations but more often run on dedicated devices called NMS systems that are developed and sold by third-party companies. An example is the HP OpenView Network Node Manager product.

Agents are individual processes running on the network devices that are being managed. These processes gather and store the status and statistics about their host platform and send them to the managers primarily in one or two ways. When the agent receives an SNMP Get request from the manager, as a Get, GetBulk, or GetNext request, it responds with the requested information. The second way is that the agent sends to the manager unsolicited notifications, called traps, that are triggered by events on the agent. The SNMP manager can also modify information on the agent by sending SNMP Set requests. A JUNOS router running SNMP is simply an SNMP agent. There are two JUNOS SNMP processes (daemons in Unix terminology): SNMPD, the SNMP process, and MIB2D, the MIB-II process. snmpd is the main entry point, or master agent, for dealing with SNMP, and it communicates with mib2d, which is a subagent.

MIBs and OIDs

SNMP agents store information in a Structure of Management Information (SMI), which is a hierarchical database that is similar to the directory structure in a filesystem. The individual files that store the information are called Management Information Bases (MIBs). Each MIB contains nodes of information that are stored in a tree structure. The tree contains branches, which move down from a root node. The branches are similar to the directory names in a directory path. Each branch eventually ends in a leaf, similar to a filename in a filesystem, that contains a specific piece of information about the SNMP agent. Each branching point in the tree corresponds to a MIB object and is identified by a number and a text string. The series of numbers that uniquely identifies a node or a leaf is called the Object Identifier (OID). As examples, OID .1.3.6.1.2.1.1.4 corresponds to sysContact (system contact information) in the standard MIB-II MIB, and OID .1.3.1.4.1.2636 corresponds to juniperMIB, which is the top node of the Juniper enterprise-specific portion of the MIB tree. Both these OIDs are absolute references because they start at the root node, which is indicated by the dot (.) before the first number (.1.3.1.4.1.2636 rather than 1.3.1.4.1.2636). In NMS and JUNOS software, you can refer to the OIDs by absolute OID or by name; the names are generally easier to remember and type. Figure 4-1 illustrates a portion of the MIB tree that leads to these OIDs and shows that each node has both text and a number to identify it.

MIB tree with OIDs
Figure 4-1. MIB tree with OIDs

The SNMP manager targets specific nodes in the MIB tree when gathering status and statistics about the agent systems.

While the OID relates to the location in the MIB tree, it is the instance that relates to the data object or value at that location. For example, the OID .1.3.6.1.2.1.1.4 corresponds to sysContact, and .1.3.6.1.2.1.1.4.0 corresponds to the value in that field, such as “Fred Flintstone.”

MIB objects can be defined as being read-only, meaning that the SNMP manager can retrieve its information only with an SNMP Get command (or with Get derivatives such as GetNext and GetBulk), or as being read-write, meaning that the manager can change the object’s information with an SNMP Set command.

MIBs are defined using a language called Abstract Syntax Notation 1 ( ASN.1). The IETF has defined a number of MIBs in various RFCs that contain objects common across all network devices. Some of these MIBs are mandatory, while others are optional. On NMS systems, most of the mandatory MIBs are typically compiled into the SNMP manager software. If you need standard MIBs that are not provided with your NMS, you can find them in the IETF RFCs and at other web sites, including http://www.net-snmp.org, http://www.rfc-editor.org, and http://net-snmp.sourceforge.net. There is a list of SMI numbers on the IANA web site (http://www.iana.org).

For objects specific to a device, the manufacturer of the device provides enterprise-specific MIBs. They must have the same structure as standard MIBs. The following example of the beginning Juniper chassis MIB illustrates the ASN.1 language:

	-- Juniper Enterprise Specific MIB: Chassis MIB
	JUNIPER-MIB DEFINITIONS ::= BEGIN
	…
	-- Juniper Box Anatomy MIB
	-- Top level objects
	jnxBoxClass OBJECT-TYPE
	    SYNTAX OBJECT IDENTIFIER
	    MAX-ACCESSread-only
	    STATUS current
	    DESCRIPTION
	         "The class of the box, indicating which product line
	         the box is about, for example, 'Internet Router'."
	    ::= { jnxBoxAnatomy 1 }

	    jnxBoxDescr OBJECT-TYPE
	    SYNTAX DisplayString (SIZE (0..255))
	    MAX-ACCESSread-only
	    STATUS current
	    DESCRIPTION
	         "The name, model, or detailed description of the box,
	         indicating which product the box is about, for example
	         'M40'."
	    ::= { jnxBoxAnatomy 2 }

	    jnxBoxSerialNo OBJECT-TYPE
	    SYNTAX DisplayString (SIZE (0..255))
	    MAX-ACCESSread-only
	    STATUS current
	    DESCRIPTION
	         "The serial number of this subject, blank if unknown
	         or unavailable."
	    ::= { jnxBoxAnatomy 3 }

These three objects provide information about the physical Juniper Networks router, specifically the family, model name, and serial number.

Juniper Networks provides several dozen enterprise MIBs for the JUNOS software. For a complete list, see http://www.juniper.net/techpubs/software/junos/mibs.html. From this page, you can download the individual MIB files or a complete MIB package that contains the relevant standard MIBs and all the enterprise MIBs. For JUNOS 7.4, this file is called juniper-mibs-7.4R1.tgz (there is a separate file for each JUNOS release). You can load this complete MIB package or the individual MIB files onto your NMS system or MIB browser. MIBs often have dependencies because they reference other MIBs, so when you load them onto the NMS, you need to load them in the correct sequence. The complete JUNOS MIB package places all objects into an SMI, which is loaded first. All the other information in the MIB files reference the SMI, so the files load correctly.

SNMP Security

SNMPv2 uses a simple security scheme to control the access between managers and servers. Security is controlled by a community string, which is a password that the NMS system uses to access the agent’s MIBs. The community string is a very weak password because it is not encrypted but rather is sent as clear text across the network. All SNMP requests from the manager to the agent must be configured with the same community name for the manager to be able to collect information from the agent. Because the password is not encrypted, the JUNOS SNMP implementation does not support most SNMP Set operations and read-write MIB objects, even those specified as read-write in the MIB RFCs. The exceptions are the ping and the traceroute MIBs, for which JUNOS supports Set operations. Some additional security is provided by the fact that you can limit the MIBs and specific objects that the NMS systems can access on the agent by configuring SNMP views on the router and granting access to specific views by community (see RFC 3415).

SNMPv3 defines a USM to provide authentication and data encryption. It uses the HMAC with either MD5 or SHA1 to authenticate users, and CBC-DES to encrypt the message payload.

4.1. Configuring SNMP

Problem

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

Solution

Use the following commands to configure the router to be an SNMP agent:

	[edit]
	aviva@router1# set snmp community public authorization read-only
	aviva@router1# show
	 
snmp {
	    community public {
	        authorization read-only;
	    }
	}

Discussion

To make the router an SNMP agent, configure one or more communities to authorize the NMS to access your router. Each community has a name, which must be the same name used by the NMS, and an authorization level (read-only or read-write). Here, we have configured one community called public with read-only access, which means that the router responds only to Get requests from the NMS system.

Use the following command to check that SNMP is up and running, that requests are being properly transmitted, and that the number of requests is incrementing over time:

	aviva@router1> show snmp statistics
	SNMP statistics:
	  Input:
	    Packets: 24044, Bad versions: 0, Bad community names: 0,
	    Bad community uses: 0, ASN parse errors: 0,
	    Too bigs: 0, No such names: 0, Bad values: 0,
	    Read onlys: 0, General errors: 0,
	    Total request varbinds: 24041, Total set varbinds: 0,
	    Get requests: 3, Get nexts: 24041, Set requests: 0,
	    Get responses: 0, Traps: 0,
	    Silent drops: 0, Proxy drops: 0, Commit pending drops: 0,
	    Throttle drops: 0, Duplicate request drops: 0
	  V3 Input:
	    Unknown security models: 0, Invalid messages: 0
	    Unknown pdu handlers: 0, Unavailable contexts: 0
	    Unknown contexts: 0, Unsupported security levels: 0
	    Not in time windows: 0, Unknown user names: 0
	    Unknown engine ids: 0, Wrong digests: 0, Decryption errors: 0
	  Output:
	    Packets: 24044, Too bigs: 0, No such names: 3,
	    Bad values: 0, General errors: 0,
	    Get requests: 0, Get nexts: 0, Set requests: 0,
	    Get responses: 24044, Traps: 0

The output shows the number and types of packets the router has received from and sent to the NMS. If you see any bad (invalid) community names, or if the number of names increases, this can indicate that one or more community names are configured incorrectly, or that an unauthorized manager, possibly a malicious user, is trying to access the agent.

4.2. Setting Router Information for the MIB-II System Group

Problem

You need to define specific information about the router, such as its name and location, to pass to the SNMP manager.

Solution

Set description, location, and contact information about the router:

	[edit snmp]
	aviva@router1# set description "JUNOS cookbook M20, aka router1"
	aviva@router1# set location "JUNOS cookbook kitchen"
	aviva@router1# set contact "aviva at extension 12345"

Discussion

These commands provide general information, which is placed into objects in the MIB-II system group, about the router to the SNMP manager. The description string identifies the router and is placed into the sysDescription object. The location describes the router’s physical location and is placed into the sysLocation object. The contact identifies how to contact the router’s administrator and goes into the sysContact object. The name of the router you configured when you installed the router (the name in the set system host-name command) is placed into the sysName object. You can set a different router name to be used just for SNMP:

	[edit snmp]
	aviva@router1# set name junos-cookbook-router

You can use a utility like snmpwalk from a Unix workstation to retrieve the agent’s information. ( snmpwalk uses SNMP GetNext requests to query a network entity for a tree of information.) The following command uses the hostname of the agent (router1), but you can also use the IP address:

	aviva-server> snmpwalk -c public router1 system.sysDescr
	system.sysDescr.0 = JUNOS cookbook M20, aka router1
	aviva-server> snmpwalk -c public router1 system.sysContact
	system.sysContact.0 = aviva at extension 12345

You can also get this information on the router itself. The following command shows all the settings in the system MIB:

	aviva@router1> show snmp mib walk system
	sysDescr.0    = JUNOS cookbook M20, aka router1
	sysObjectID.0 = jnxProductNameM20
	sysUpTime.0   = 2888368
	sysContact.0  = aviva at extension 12345
	sysName.0     = junos-cookbook-router
	sysLocation.0 = JUNOS cookbook kitchen
	sysServices.0 = 4

You can also look at a single MIB object:

	aviva@router1> show  
snmp mib get sysDescr.0
	sysDescr.0    = JUNOS cookbook M20, aka router1

In this command, specify both the name of the object and the instance, which is 0. Similarly, you can look at more than one object:

	aviva@router1> show snmp mib get "sysUpTime.0 sysName.0"
	sysUpTime.0   = 2865092
	sysName.0     = router1

For this command to work, make sure to enclose the list of objects in quotation marks.

See Also

Recipe 1.1

4.3. Setting Up SNMP Traps

Problem

You want to create triggers on the router to send unsolicited notifications to the NMS system when a router event occurs.

Solution

Configure traps by setting up SNMP trap groups:

	[edit snmp]
	aviva@router1# set trap-group authentication-traps targets 10.0.10.1
	aviva@router1# set trap-group authentication-traps targets 192.168.15.27
	aviva@router1# set trap-group authentication-traps categories authentication

Discussion

SNMP traps report significant events that occur on the router, commonly errors or failures. You always want the SNMP agent to send traps to the manager so that the manager receives current information without always having to poll for it. To have the router send traps to the SNMP manager, create one or more trap groups. For each group, set two things: the IP address of the NMS server (or servers) to receive the trap and the events that trigger the traps. The targets statement identifies the receiving NMS systems, and the categories statement specifies the triggering event or events (see Table 4-1). The JUNOS software supports standard trap categories and provides several that are enterprise-specific. This recipe sends a trap to two NMS systems (our primary system and a backup one for redundancy) whenever an SNMP manager uses the incorrect community to access data held by the agent.

Table 4-1. SNMP trap categories

Keyword

Type

Category description

authentication

Standard

Agent (router) authentication failures

chassis

Enterprise

Chassis and router environment notifications

configuration

Enterprise

Configuration mode notifications

link

Enterprise

Link-related transitions, such as when hardware transitions from up to down, or vice versa

rmon-alarm

Enterprise

RMON event alarms

routing

Enterprise

Routing protocol notifications

sonet-alarms alarm-name

Enterprise

SONET alarm notifications

startup

Standard

Router warm and full reboots

vrrp-events

Enterprise

VRRP events

SNMP traps are defined in the MIBs themselves. The IETF defines the standard traps in various RFCs, and they are normally compiled into the SNMP manager software that runs on the NMS system. Juniper Networks defines enterprise-specific traps for SNMPv1 and SNMPv2 and sends both versions of the traps to the NMS. To find a list and an explanation of the JUNOS traps, look in the enterprise MIBs, searching for the string NOTIFICATION-TYPE in the MIB. For example, in the Juniper Networks chassis MIB, the OID for the trap that reports the failure of a power supply, jnxPowerSupplyFailure, is jnxChassisTraps 1:

	-- definition of chassis related traps
	Traps for chassis alarm conditions
	jnxPowerSupplyFailure NOTIFICATION-TYP
	    OBJECTS…
	    STATUS current
	    DESCRIPTION
	"A jnxPowerSupplyFailure trap signifies that the SNMP entity, acting in an agent
	role, has detected that the specified power supply in the chassis has been in the
	failure (bad DC output) condition."
	::= { jnxChassisTraps 1 }

4.4. Controlling SNMP Access to the Router

Problem

You need to improve upon the security offered by the SNMPv2 community password.

Solution

There are two straightforward solutions. One is to identify which NMS systems are allowed to use the SNMP community:

	[edit snmp]
	aviva@router1# set community public clients 10.0.0.1/32

The second is to limit the router interfaces that can communicate with the NMS system:

	[edit  
snmp]
	aviva@router1# set interface [fe-0/0/0]

Discussion

SNMPv2 is inherently insecure because the community string, which acts as the password between the manager and agent, is sent as clear text across the network. You can improve the security a bit by limiting SNMP manager access to the router and to the MIB on the router. Perhaps the simplest way to improve security is to define which NMS systems can or cannot use a particular community string. The first command in this recipe allows only a single system, 10.0.10.1/32, to access the router using the community string public. While this example and the examples throughout this chapter use a community named public, this name is very well known, so for security reasons, it is recommended that you use a different name, preferably one that’s difficult to guess (for example, mYsnmPcommunitYversioNonE).

You can also disallow access for specific NMS systems. One plausible use of this is to allow access by all the NMS systems on a subnet and then deny access to just a few:

	[edit snmp]
	aviva@router1# set community public clients 10.0.0.0/8
	aviva@router1# set community public clients 10.0.0.1/32 restrict

This configuration allows all NMS systems on the 10.0.0.0/8 subnet to access the router, with the exception of 10.0.0.1/32.

Another way to restrict access is to define which router interfaces can receive requests from NMS systems. The second command in this recipe does this by specifying a physical interface, or you can name individual logical interfaces to be more specific:

	[edit snmp]
	aviva@router1# set interface [fe-0/0/0.0 fe-0/0/0.1]

See Also

The introduction to Chapter 7

4.5. Using a Firewall Filter to Protect SNMP Access

Problem

You have a firewall filter on your interfaces and want to add a term to restrict NMS system access to the router.

Solution

You can add a term to the existing firewall filter that allows access to the desired NMS systems:

Add a term to an existing firewall filter that restricts SSH and Telnet access:

	[edit firewall filter protect-RE term allow- 
snmp-from-nms-systems]
	aviva@router1# set from source-address 10.0.0.1/32
	aviva@router1# set from source-address 10.0.5.1/32
	aviva@router1# set from source-address 10.0.6.1/34
	aviva@router1# set from source-address 10.10.1.50/32
	aviva@router1# set from protocol udp
	aviva@router1# set from destination-port snmp
	aviva@router1# set then accept

For the filter to affect incoming traffic, apply it to the desired interfaces:

	[edit interfaces]
	aviva@router1# set fe-0/0/0 unit 0 family inet filter input protect-RE

Discussion

An interface can have one inbound and one outbound firewall filter, so if you already have filters in place that control the incoming and outgoing interface traffic, you can add a term that applies to NMS access. To filter polling requests from NMS systems, add the term to the inbound filter; to filter the router’s responses, add it to the outbound filter. This term allows four NMS systems, all identified by IP address, to send SNMP requests to the router. The destination-port option matches the SNMP port number in the IP packet’s destination field, and you include the udp option because SNMP exchanges use UDP, not TCP.

You then have to decide where in the filter to place the term. Because the terms in the firewall filter are evaluated in the order in which they appear, the placement affects the efficiency of the filter. Generally, terms for operations that need to be performed quickly, such as BGP peering and IGP and DNS traffic, are at the beginning of the filter. For operations that are less time-critical, including processing SNMP traffic, place the term towards the end of the filter.

For the filter to do anything, you apply it to the desired interface with the set filter input command.

To create a parallel filter for outbound SNMP traffic, you can incorporate the same term into the interface’s outbound firewall filter and then apply it on the ongoing side:

	[edit interfaces]
	aviva@router1# set fe-0/0/0 unit 0 family inet filter output outgoing-from-me

Fashion the firewall filter for outgoing SNMP a bit differently to allow the router to send SNMP traps. Specify a source port of snmp (port 161) and a destination port of snmptrap (port 162):

	[edit firewall filter outgoing-from-me]
	aviva@router1# set term allow- 
snmp-to-nms-systems source-port snmp
	aviva@router1# set term allow-snmp-to-nms-systems destination-port snmptrap

Instead of listing addresses individually in the from source-address portion of the configuration, a shortcut creates a prefix list and then just references the list. A prefix list is simply a named list of IP prefixes created in the [edit policy-options] portion of the configuration and then referred to in firewall filters and in routing policies.

See Also

Recipes 9.3, 9.15, and 9.16

4.6. Controlling Access to Router MIBs

Problem

You want to limit the access of a group of NMS systems so they can gather only basic system and chassis information from the router.

Solution

Use the following commands to define the MIB branches that a community can 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

Then associate the MIB view with the community:

	[edit snmp]
	aviva@router1#  
set community chassis-access-only view chassis-info-only

Discussion

By default, an SNMP community can access the whole MIB installed on the router. You can limit the MIB access that a community has by creating partial views of the MIB. This recipe creates a community that can view information only about objects in the Juniper Networks chassis MIB and in the standard MIB-II MIB. Controlling access consists of two steps: create the view itself using the set view commands and then associate the view with the community using the set community command.

If you want a community to be able to read most but not all of the MIB, you can restrict access to just a few MIB branches.

You might want to give access to all MIB branches except the two in which the JUNOS software allows SNMP Set operations, the ping and traceroute MIB branches:

	[edit snmp]
	aviva@router1# set view ping-traceroute-exclude oid jnxPingMIB exclude
	aviva@router1# set view ping-traceroute-exclude oid jnxTraceRouteMIB exclude
	aviva@router1# set community public view ping-traceroute-exclude

4.7. Extracting Software Inventory Information with SNMP

Problem

You want to use SNMP to retrieve software version information from the router.

Solution

From an NMS system, use the snmpwalk command:

	aviva-server1% snmpwalk 192.168.15.1 public .1.3.6.1.2.1.25.6.3
	…
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.2 = "JUNOS
	Base OS Software Suite [7.4R1.7.0]"
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.3 = "JUNOS
	Kernel Software Suite [7.4R1.7.0]"
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.4 = "JUNOS
	Packet Forwarding Engine Support (M20/M40) [7.4R1.7.0]"
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.5 = "JUNOS
	Routing Software Suite [7.4R1.7.0]"
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.6 = "JUNOS
	Online Documentation [7.4R1.7.0]"
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.7 = "JUNOS
	Crypto Software Suite [7.4R1.7.0]"
	host.hrSWInstalled.hrSWInstalledTable.hrSWInstalledEntry.hrSWInstalledName.9 = "JUNOS
	Support Tools Package [7.4R1.7.0]"

From the router, use the following equivalent command:

	aviva@router1> show snmp mib walk .1.3.6.1.2.1.25.6.3
	hrSWInstalledName.2 = JUNOS Base OS Software Suite [7.4R1.7.0]
	hrSWInstalledName.3 = JUNOS Kernel Software Suite [7.4R1.7.0]
	hrSWInstalledName.4 = JUNOS Packet Forwarding Engine Support (M20/M40) [7.4R1.7.0]
	hrSWInstalledName.5 = JUNOS Routing Software Suite [7.4R1.7.0]
	hrSWInstalledName.6 = JUNOS Online Documentation [7.4R1.7.0]
	hrSWInstalledName.7 = JUNOS Crypto Software Suite [7.4R1.7.0]
	hrSWInstalledName.9 = JUNOS Support Tools Package [7.4R1.7.0]

Discussion

The SNMP standard Host Resources MIB, specified in RFC 2790, contains objects that allow you to retrieve the versions of the software running on the router. The absolute path to the OID for installed software is .1.3.6.1.2.1.25.6.3. From the CLI, you get this same information with the show version command (see Recipe 1.25):

	aviva@router1> show version
	Hostname: router1
	Model: m20
	JUNOS Base OS boot [7.4-20051024.0]
	JUNOS Base OS Software Suite [7.4-20051024.0]
	JUNOS Kernel Software Suite [7.4R1.7]
	JUNOS Packet Forwarding Engine Support (M20/M40) [7.4R1.7]
	JUNOS Routing Software Suite [7.4R1.7]
	JUNOS Online Documentation [7.4R1.7]
	JUNOS Crypto Software Suite [7.4R1.7]

In the SNMP output, the software version is shown as 7.42R1.7.0, which includes the instance (.0) of the software package.

See Also

Recipe 1.25

4.8. Extracting Hardware Inventory Information with SNMP

Problem

You want to use SNMP to find out router hardware information and which field-replaceable units (FRUs) are present in the router.

Solution

If you are logged in to the router, you can get information using the show snmp mib commands. To get information about a single router component:

	aviva@router1> show snmp mib get sysObjectID.0
	sysObjectID.0 = jnxProductNameJ230M20

To get information about the next router component in the MIB:

	aviva@router1> show snmp mib get jnxBoxClass.0
	jnxBoxClass.0 = jnxProductLineM20.0
	aviva@router1> show snmp mib get-next jnxBoxClass.0
	jnxBoxDescr.0 = Juniper m20 Internet Backbone Router

For information about a number of router components, list each one separately:

	aviva@router1> show snmp mib get "jnxBoxClass.0 jnxBoxClass.0"
	jnxBoxClass.0 = jnxProductLineM20.0
	jnxBoxClass.0 = jnxProductLineM20.0

To get information about all the router components:

	aviva@router1> show snmp mib walk jnxBoxAnatomy
	jnxBoxClass.0 = jnxProductLineM20.0
	jnxBoxDescr.0 = Juniper m20 Internet Backbone Router
	jnxBoxSerialNo.0 = 25708
	…
	jnxContainersType.1 = jnxChassisM20.0
	jnxContainersType.2 = jnxM20SlotPower.0
	jnxContainersType.4 = jnxM20SlotFan.0
	jnxContainersType.6 = jnxM20SlotSSB.0
	jnxContainersType.7 = jnxM20SlotFPC.0
	jnxContainersType.8 = jnxM20MediaCardSpacePIC.0
	jnxContainersType.9 = jnxM20SlotRE.0
	jnxContainersType.10 = jnxM20SlotFrontPanel.0
	jnxContainersDescr.1 = chassis frame
	jnxContainersDescr.2 = Power Supply slot
	jnxContainersDescr.4 = Fan slot
	jnxContainersDescr.6 = SSB slot
	jnxContainersDescr.7 = FPC slot
	jnxContainersDescr.8 = PIC slot
	jnxContainersDescr.9 = Routing Engine slot
	jnxContainersDescr.10 = Front Panel Display slot
	…

To get information about the FRUs, walk through the jnxContentsTable object:

	aviva@router1> show snmp mib walk jnxContentsTable
	…
	jnxContentsType.1.1.0.0 = jnxBackplaneM20.0
	jnxContentsType.2.1.0.0 = jnxM20Power.0
	jnxContentsType.4.1.0.0 = jnxM20Fan.0
	jnxContentsType.4.2.0.0 = jnxM20Fan.0
	jnxContentsType.4.3.0.0 = jnxM20Fan.0
	jnxContentsType.4.4.0.0 = jnxM20Fan.0
	jnxContentsType.6.1.0.0 = jnxM20SSB.0
	jnxContentsType.6.2.0.0 = jnxM20SSB.0
	jnxContentsType.7.1.0.0 = jnxM20FPC.0
	jnxContentsType.7.2.0.0 = jnxM20FPC.0
	jnxContentsType.8.1.1.0 = jnxM20QuadEther.0
	jnxContentsType.8.1.2.0 = jnxM20DualChDs3toDs0.0
	jnxContentsType.8.1.3.0 = jnxM20QuadChT3.0
	jnxContentsType.8.2.1.0 = jnxM20DualAtmOc3.0
	jnxContentsType.9.1.0.0 = jnxM20RE.0
	jnxContentsType.9.1.1.0 = jnxPCMCIACard.0
	jnxContentsType.9.2.0.0 = jnxM20RE.0
	jnxContentsType.9.2.1.0 = jnxPCMCIACard.0
	jnxContentsType.10.1.0.0 = jnxM20FrontPanel.0

Discussion

In the Juniper Networks chassis MIB, router family information is in the jnxBoxAnatomy object and FRU information is in the jnxContentsTable object. On the router, you use the show snmp mib commands to collect data from these objects.

The three variations, show snmp mib get, show snmp mib get-next, and show snmp mib walk, are identical to the snmpget, snmpgetnext, and snmpwalk commands, respectively.

For the NMS system to extract this data, it needs to access the Juniper Networks chassis MIB to parse the MIB objects in the jnxBoxAnatomy and jnxContentsTable objects.

You can collect a range of information for each FRU. Here, we show data about the Routing Engine in slot 0:

	aviva@router1> show snmp mib get jnxContentsType.9.1.0.0
	jnxContentsType.9.1.0.0 = jnxM20RE.0
	aviva@router1> show snmp mib get jnxContentsDescr.9.1.0.0
	jnxContentsDescr.9.1.0.0 = Routing Engine 0
	aviva@router1> show snmp mib get jnxContentsSerialNo.9.1.0.0
	jnxContentsSerialNo.9.1.0.0 = 58000007348d9a01
	aviva@router1> show snmp mib get jnxContentsRevision.9.1.0.0
	jnxContentsRevision.9.1.0.0 = REV 06

If you are gathering hardware inventory information on the router, you use the show chassis hardware command (see Recipe 1.26):

	aviva@router1> show chassis hardware
	 
Hardware inventory:
	Item             Version  Part number   Serial number   Description
	Chassis                                 25708           M20
	Backplane        REV 03   710-002334    BB9738          M20 Backplane
	Power Supply A   REV 06   740-001465    005234          AC Power Supply
	Display          REV 04   710-001519    BA4681          M20 FPM Board
	Routing Engine 0 REV 06   740-003239    1000224893      RE-2.0
	Routing Engine 1 REV 06   740-003239    9000022146      RE-2.0
	SSB slot 0       REV 02   710-001951    AZ8112          Internet Processor IIv1
	SSB slot 1       N/A      N/A           N/A             Backup
	FPC 0            REV 03   710-003308    BD8455          E-FPC
	  PIC 0          REV 08   750-002303    AZ5310          4x F/E, 100 BASE-TX
	  PIC 1          REV 07   750-004745    BC9368          2x CT3-NxDS0
	  PIC 2          REV 03   750-002965    HC9279          4x CT3
	FPC 1            REV 03   710-003308    BB9032          E-FPC
	  PIC 0          REV 03   750-002914    BC0131          2x OC-3 ATM, MM

4.9. Collecting Router Operational Information with SNMP

Problem

You want the NMS server to check and record operational information about the router.

Solution

Look at the contents of the jnxOperatingTable table in the chassis MIB:

	aviva@router1> show snmp mib walk jnxOperatingTable
	…
	jnxOperatingDescr.1.1.0.0 = backplane
	jnxOperatingDescr.2.1.0.0 = Power Supply A
	jnxOperatingDescr.4.1.0.0 = Front Upper Fan
	jnxOperatingDescr.4.2.0.0 = Front Middle Fan
	jnxOperatingDescr.4.3.0.0 = Front Bottom Fan
	jnxOperatingDescr.4.4.0.0 = Rear Fan
	jnxOperatingDescr.6.1.0.0 = SSB 0 Internet Processor IIv1
	jnxOperatingDescr.6.2.0.0 = SSB 1
	jnxOperatingDescr.7.1.0.0 = FPC: E-FPC @ 0/*/*
	jnxOperatingDescr.7.2.0.0 = FPC: E-FPC @ 1/*/*
	jnxOperatingDescr.8.1.1.0 = PIC: 4x F/E, 100 BASE-TX @ 0/0/*
	jnxOperatingDescr.8.1.2.0 = PIC: 2x CT3-NxDS0 @ 0/1/*
	jnxOperatingDescr.8.1.3.0 = PIC: 4x CT3 @ 0/2/*
	jnxOperatingDescr.8.2.1.0 = PIC: 2x OC-3 ATM, MM @ 1/0/*
	jnxOperatingDescr.9.1.0.0 = Routing Engine 0
	jnxOperatingDescr.9.2.0.0 = Routing Engine 1
	jnxOperatingDescr.10.1.0.0 = Front Panel Display
	jnxOperatingTemp.1.1.0.0 = 22
	jnxOperatingTemp.2.1.0.0 = 22
	jnxOperatingTemp.4.1.0.0 = 0
	jnxOperatingTemp.4.2.0.0 = 0
	jnxOperatingTemp.4.3.0.0 = 0
	jnxOperatingTemp.4.4.0.0 = 0
	jnxOperatingTemp.6.1.0.0 = 30
	jnxOperatingTemp.6.2.0.0 = 0
	jnxOperatingTemp.7.1.0.0 = 28
	jnxOperatingTemp.7.2.0.0 = 27
	jnxOperatingTemp.8.1.1.0 = 0
	jnxOperatingTemp.8.1.2.0 = 0
	jnxOperatingTemp.8.1.3.0 = 0
	jnxOperatingTemp.8.2.1.0 = 0
	jnxOperatingTemp.9.1.0.0 = 29
	jnxOperatingTemp.9.2.0.0 = 31
	jnxOperatingTemp.10.1.0.0 = 0
	…

Discussion

The jnxOperatingTable table in the chassis MIB lists all the components installed in the chassis along with information about their operation state. This table has an absolute OID of .1.3.6.1.4.1.2636.3.1.13.

The abridged output in the recipe shows the router hardware components and the current temperature (in degrees Celsius) for each component. This table contains much more information about the hardware, such as DRAM size (in bytes) for components that have memory:

	jnxOperatingDRAMSize.6.1.0.0 = 67108864
	jnxOperatingDRAMSize.7.1.0.0 = 33554432
	jnxOperatingDRAMSize.7.2.0.0 = 33554432
	jnxOperatingDRAMSize.9.1.0.0 = 805306368
	jnxOperatingDRAMSize.9.2.0.0 = 805306368

Referring back to the list of hardware components, jnxOperatingDRAMSize.6.1.0.0 is the router’s System and Switch Board ( SSB), which handles forwarding for M20 routers. The other items are the FPC0 and FPC1 boards and the two Routing Engines. The output also shows how long a component has been up:

	jnxOperatingUpTime.1.1.0.0 = 35718300
	jnxOperatingUpTime.2.1.0.0 = 35719533
	jnxOperatingUpTime.4.1.0.0 = 35719534
	jnxOperatingUpTime.4.2.0.0 = 35719535
	jnxOperatingUpTime.4.3.0.0 = 35719536
	jnxOperatingUpTime.4.4.0.0 = 35719537
	jnxOperatingUpTime.6.1.0.0 = 6515160
	jnxOperatingUpTime.6.2.0.0 = 0
	jnxOperatingUpTime.7.1.0.0 = 6511883
	jnxOperatingUpTime.7.2.0.0 = 6511798
	jnxOperatingUpTime.8.1.1.0 = 6509154
	jnxOperatingUpTime.8.1.2.0 = 6509150
	jnxOperatingUpTime.8.1.3.0 = 6509100
	jnxOperatingUpTime.8.2.1.0 = 6508973
	jnxOperatingUpTime.9.1.0.0 = 35718300
	jnxOperatingUpTime.9.2.0.0 = 1978055600
	jnxOperatingUpTime.10.1.0.0 = 35719549

The output shows that RE0 has been up for 35,718,300 10-second intervals, which is about 99 hours, or just over 4 days. You can confirm the Routing Engine information shown in the MIB objects with the following CLI command:

	aviva@router1> show chassis routing-engine
	Routing Engine status:
	  Slot 0:
	    Current state                  Master
	    Election priority              Master (default)
	    Temperature                 29 degrees C / 84 degrees F
	    CPU temperature             30 degrees C / 86 degrees F
	    DRAM                       768 MB
	    Memory utilization          36 percent
	CPU utilization:
	  User                           0 percent
	  Background                     0 percent
	  Kernel                         1 percent
	  Interrupt                      0 percent
	  Idle                          99 percent
	Model                              RE-2.0
	Serial ID                          58000007348d9a01
	Start time                         2005-12-07 13:28:55 PST
	Uptime                            4 days, 3 hours, 57 minutes, 35 seconds
	Load averages:                     1 minute 5 minute 15 minute
	                                       0.07     0.05      0.02

4.10. Logging SNMP Access to the Router

Problem

You want to keep a log of SNMP operations that occur on the router and of the NMS systems that connect to the router to gather status and statistics.

Solution

Use the following command to log SNMP operations and NMS connections:

	[edit snmp]
	aviva@router1# set traceoptions flag pdu

Discussion

You log SNMP access and operations by using SNMP trace logging. By default, the log messages are saved to a number of tracing files in the /var/log directory, including snmpd.

To see which NMS systems have connected to the router, this recipe sets the PDU tracing flag, which logs all NMS system request and responses to them, as well as any traps that get generated. To see the PDU traces, look in the /var/log/snmpd file:

	Apr 27 12:04:34 snmpd[1370dced] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
	Apr 27 12:04:34 snmpd[1370dced] >>> Get-Request
	Apr 27 12:04:34 snmpd[1370dced] >>> Source: 172.16.20.182
	Apr 27 12:04:34 snmpd[1370dced] >>> Destination: 192.168.15.1
	Apr 27 12:04:34 snmpd[1370dced] >>> Version: SNMPv2
	Apr 27 12:04:34 snmpd[1370dced] >>> Request_id: 0x1370dced
	Apr 27 12:04:34 snmpd[1370dced] >>> Community: public
	Apr 27 12:04:34 snmpd[1370dced] >>> Error: status=0 / vb_index=0
	Apr 27 12:04:34 snmpd[1370dced] >>> OID : sysName.0
	Apr 27 12:04:34 snmpd[1370dced] >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
	Apr 27 12:04:34 snmpd[1370dced]  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	Apr 27 12:04:34 snmpd[1370dced]  <<< Get-Response
	Apr 27 12:04:34 snmpd[1370dced]  <<< Source: 192.168.15.1
	Apr 27 12:04:34 snmpd[1370dced]  <<< Destination: 172.16.20.182
	Apr 27 12:04:34 snmpd[1370dced]  <<< Version: SNMPv2
	Apr 27 12:04:34 snmpd[1370dced]  <<< Request_id: 0x1370dced
	Apr 27 12:04:34 snmpd[1370dced]  <<< Community: public
	Apr 27 12:04:34 snmpd[1370dced]  <<< Error: status=0 / vb_index=0
	Apr 27 12:04:34 snmpd[1370dced]  <<< OID : sysName.0
	Apr 27 12:04:34 snmpd[1370dced]  <<< type : OctetString
	Apr 27 12:04:34 snmpd[1370dced]  <<< value: "router1"
	Apr 27 12:04:34 snmpd[1370dced]  <<< HEX : 74 61 6e 71 75 65 72 61
	Apr 27 12:04:34 snmpd[1370dced]  <<< 79
	Apr 27 12:04:34 snmpd[1370dced]  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

This output shows a Get request from the NMS system 172.16.20.182 for the OID sysName. The router returned the value of router1 in its Get-Response message.

See Also

Recipe 5.1

4.11. Logging Enterprise-Specific Traps

Problem

You want to collect Juniper Networks enterprise-specific traps in the router’s system logging files.

Solution

Use the following commands to save all log messages to a file called snmp-critical-traps:

	[edit]
	user@router1# edit system syslog file snmp-critical-traps
	[edit system syslog file snmp-critical-traps]
	user@router1# set daemon critical

Discussion

The traps from the Juniper Networks chassis MIB all have a system logging severity level associated with them. You can take advantage of this to collect these traps in a system logfile. The chassis traps record chassis component information that is critical to the operation of the router, such as power supply and fan failures. In this recipe, we collect all critical and alert logging messages generated by all JUNOS processes, including SNMPD and MIB2D, which captures most of the SNMP chassis traps.

Table 4-2 shows all the chassis traps and their corresponding severity level. In the system logging file, these messages are prefixed with the identifier CHASSISD_SNMP_TRAP.

Table 4-2. System logging severity levels for Juniper Networks chassis SNMPv2 traps

Severity level

Chassis SNMPv2 trap

Notice

jnxFruInsertion

 

Insertion of a replaceable chassis component

 

jnxFruPowerOff

 

Powering down of a replaceable chassis component

 

jnxFruPowerOn

 

Powering up of a replaceable chassis component

 

jnxFruRemoval

 

Removal of a replaceable chassis component

Critical

jnxFanFailure

 

Chassis fan or impeller failure

 

jnxFanOK

 

Chassis fan or impeller recovery

 

jnxOverTemperature

 

Overheating of a hardware component

 

jnxPowerSupplyOK

 

Power supply recovery

 

jnxRedundancySwitchOver

 

Chassis component has switched from master to backup, or vice versa

Alert

jnxPowerSupplyFailure

 

Power supply failure

 

jnxTemperatureOK

 

Overheating recovery by a hardware component

The Juniper Networks chassis MIB traps are the only enterprise-specific traps that are associated with a system logging severity level, so they are the only ones that you can specifically log.

See Also

Recipe 5.1

4.12. Using RMON Traps to Monitor the Router’s Temperature

Problem

You want to use remote monitoring (RMON) to have the router monitor and proactively report on overtemperature conditions in the router.

Solution

Create an RMON trap that watches the internal temperature of the router by tracking the backplane temperature:

	[edit snmp]
	aviva@router1# set trap-group overtemperature
	aviva@router1# set trap-group overtemperature categories rmon-alarm
	aviva@router1# set trap-group overtemperature targets 10.0.10.1
	aviva@router1# edit rmon
	[edit snmp rmon]
	aviva@router1# set alarm 1 description "overtemperature for M20 backplane"
	aviva@router1# set alarm 1 interval 300
	aviva@router1# set alarm 1 variable jnxOperatingTemp.1.1.0.0
	aviva@router1# set alarm 1 sample-type absolute-value
	aviva@router1# set alarm 1 rising-threshold 40
	aviva@router1# set alarm 1 startup-alarm rising-alarm
	aviva@router1# set alarm 1 rising-event-index 1
	aviva@router1# set event 1 description Heap-Events
	aviva@router1# set event 1 type log-and-trap
	aviva@router1# set event 1 community heap-traps

This is an involved configuration, so here’s what it looks like when viewed all together:

	[edit snmp]
	aviva@router1# show
	trap-group overtemperature {
	     categories {
	         rmon-alarm;
	     }
	     targets {
	         10.0.10.1;
	     }
	}
	rmon {
	     alarm 1 {
	          description "overtemperature for M20 backplane";
	          interval 300;
	          variable jnxOperatingTemp.1.1.0.0;
	          sample-type absolute-value;
	          rising-threshold 40;
	          rising-event-index 1;
	     }
	     event 1 {
	          description Overtemperature-Events;
	          type log-and-trap;
	          community overtemperature;
	     }
	}

Discussion

RMON is an SNMP specification that allows an SNMP agent (your router) to proactively monitor its system health and performance and then send traps to an SNMP manager. The local SNMP agent compares MIB values against predefined thresholds and generates exception alarms without the need for polling by a central SNMP management platform. This is an effective mechanism for proactive management, provided that you have baselined and set the thresholds correctly. RMON also decreases the amount of traffic between the manager and the router because the SNMP manager does not always have to poll for information and it allows the manager to get more timely status reports because the router reports events as they occur.

You can monitor many things. This recipe monitors the router’s backplane temperature. The backplane is in the center of the router, so the temperature gives you an idea of whether the router might be overheating. This recipe sets the threshold at 40 degrees Celsius. When this value is exceeded, an RMON event is triggered, a trap is sent, and the event is logged.

To set up RMON, configure the OID and the threshold values that trigger the alarm (with the set alarm commands), the router’s response to the alarm (with the set event commands), and the NMS systems to receive the trap (with the set trap-group commands).

The alarm’s threshold value can be an actual value, as in these two alarms (set with the sample-type statement and absolute-value option), or the difference between the current value and the last value (set with the delta-value option).

Finally, choose a number to identify the alarm and to link the alarm with the event. Specify the number in the rising-alarm-index statement when monitoring a rising threshold or in the falling-alarm-index statement when monitoring a falling threshold. For alarm 1, rising-alarm-index 1 associates event 1 with this alarm.

The event statement hierarchy defines the router’s response to the alarm. In this recipe, the type log-and-trap statement logs both sets of traps. The community statement associates the events with the trap group overtemperature, which sends the traps to the NMS system defined in the targets statement.

When you configure the trap group to handle the RMON event, the category must be rmon-alarm. The targets are all the NMS systems to receive the trap.

Events are generated only when the threshold is first crossed in any one direction, not after each sample period. Once the threshold is crossed, no more events are generated until after the value crosses back into the normal range and again crosses the threshold. This mechanism considerably reduces the quantity of alarms produced by the router, making it easier for you to react when alarms do occur. Keep in mind that because SNMP uses UDP, there is no guarantee of the delivery of the alarm to the SNMP manager.

To verify that the RMON alarm is set, use the following command on the router:

	aviva@router1> show snmp rmon alarms
	Alarm
	Index  Variable description                           Value State
	     1 monitor: overtemperature for M20 backplane
	       jnxOperatingTemp.1.1.0.0
	                                                         22 falling threshold

The Value column in the output shows the current value of the object, which here is 22 degrees. You can verify the temperature by looking at the object’s value directly:

	aviva@router1> show snmp mib get jnxOperatingTemp.1.1.0.0
	jnxOperatingTemp.1.1.0.0 = 22

You can also see it with the show chassis environment command:

	aviva@router1> show chassis environment
	Class Item                   Status     Measurement
	Power Power Supply A         OK
	      Power Supply B         Absent
	Temp FPC 0                   OK         28 degrees C / 82 degrees F
	     FPC 1                   OK         27 degrees C / 80 degrees F
	     Power Supply A          OK         22 degrees C / 71 degrees F
	     Power Supply B          Absent
	     SSB 0                   OK         30 degrees C / 86 degrees F
	     Backplane               OK         22 degrees C / 71 degrees F
	     Routing Engine 0        OK         30 degrees C / 86 degrees F
	     Routing Engine 1        OK         31 degrees C / 87 degrees F
	Fans Rear Fan                OK         Spinning at normal speed
	     Front Upper Fan         OK         Spinning at normal speed
	     Front Middle Fan        OK         Spinning at normal speed
	     Front Bottom Fan        OK         Spinning at normal speed
	Misc Craft Interface         OK

To see the events that are set, use this command:

	aviva@router1> show snmp rmon events
	Event
	Index Type                         Last Event
	    1 log and trap

When the backplane temperature crosses the rising threshold, you can see the log using the show snmp rmon logs command.

From the NMS system and from the router, you can retrieve RMON data from the alarmTable, eventTable, and logTable MIB objects. Here’s what you would see when looking at the alarm table from the router:

	aviva@router1> show snmp mib walk eventTable
	eventIndex.1  = 1
	eventDescription.1 = Overtemperature-Events
	eventType.1   = 4
	eventCommunity.1 = overtemperature
	eventLastTimeSent.1 = 0
	eventOwner.1
	eventStatus.1 = 1

See Also

RFC 2819, Remote Network Monitoring MIB

4.13. 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;
	}

4.14. Tracking Router Configuration Changes

Problem

You want an NMS system to track when the router’s configuration has been changed.

Solution

First, define the NMS system and its password:

	[edit snmp v3]
	aviva@router1# set  
usm local-engine user nms2 authentication-sha authentication-
	password $0212roZH
	aviva@router1# set usm local-engine user nms2 privacy-des privacy-password 0212roZH

Then, define two views that allow the NMS access to the configuration information. The first view defines what the NMS can read from the MIB:

	[edit snmp v3]
	aviva@router1# set view config-info-read oid jnxCfgMgmt include

The second view sets what the router includes in notifications sent to the NMS:

	[edit snmp v3]
	aviva@router1# set view config-info-notify oid jnxCfgMgmt include
	aviva@router1# set view config-info-notify oid jnxCmNotifications include
	aviva@router1# set view config-info-notify oid snmpMIBObjects include
	aviva@router1# set view config-info-notify oid system include

Finally, create groups and their users and assign access privileges for the groups:

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

Discussion

To use SNMP to extract the router configuration, use the Juniper Networks configuration management MIB extension, which tracks who made changes to the configuration and when. This recipe gives the NMS system called nms2 access to configuration information.

The first commands in this recipe configure USM for security, with SHA1 authentication and DES message payload encryption. You then create two views, one that defines what nms2 can read from the MIB and a second that sets what the router can include in notifications. The final commands configure the VACM to provide access to desired groups.

Again, this recipe is somewhat involved, so here’s what the resulting configuration looks like after you issue the commands in this recipe, with some added comments:

	aviva@router1# show | except SECRET-DATA
	v3 {
	    usm { # <-- which NMS systems can access the router
	        local-engine {
	            user nms2 {
	                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 nms2 {
	                    group config-only;
	                }
	            }
	         }
	         access { # <-- which MIB views the NMS systems can access
	             group config-only {
	                  default-context-prefix {
	                      security-model usm {
	                          security-level privacy {
	                              read-view config-info-read;
	                              notify-view config-info-notify;
	                          }
	                      }
	                  }
	             }
	         }
	    }
	}
	view config-info-read { # <-- view of enterprise configuration management objects
	oid jnxCfgMgmt include;
	}
	view config-info-notify { # <-- view for objects used by SNMPv3 traps
	    oid jnxCfgMgmt include;
	    oid jnxCmNotifications include;
	    oid snmpMIBObjects include;
	    oid system include;
	}

4.15. Setting Up SNMPv3 Traps

Problem

You want SNMPv3 to generate traps about chassis and configuration events and send the traps to the NMS system.

Solution

For the chassis events, first configure the trap notification:

	[edit snmp v3]
	aviva@router1# set notify chassis-notification-list type trap
	aviva@router1# set notify chassis-notification-list tag chassis-trap-receivers

Next, define the traps to send:

	[edit snmp v3]
	aviva@router1# set notify-filter chassis- 
traps oid jnxChassisTraps include
	aviva@router1# set notify-filter chassis-traps oid jnxChassisOKTraps include

Identify the NMS systems (the targets) to receive the traps:

	[edit snmp v3]
	aviva@router1# edit target-address nms1
	[edit snmp v3 target-address nms1]
	aviva@router1# set address 10.0.10.1
	aviva@router1# set tag-list chassis-trap-receivers
	aviva@router1# set target-parameters nms1-parameters

Finally, configure which traps the NMS systems receive and the security used when sending the traps:

	[edit snmp v3]
	aviva@router1# edit target-parameters nms1-parameters
	[edit snmp v3 target-parameters nms1-parameters]
	aviva@router1# set parameters message-processing-model v3
	aviva@router1# set parameters security-model usm
	aviva@router1# set parameters security-level privacy
	aviva@router1# set parameters security-name nms1
	aviva@router1# set notify-filter chassis-traps

To set up traps that correspond to the JUNOS configuration management MIB extension we showed in Recipe 4.14, configure them in a similar way. First, set up the trap notification:

	[edit snmp v3]
	aviva@router1# set notify config-notification-list type trap
	aviva@router1# set notify config-notification-list tag config-trap-receivers

Next, define the trap to send:

	[edit snmp v3]
	aviva@router1# set notify-filter config-traps oid jnxCmNotifications include

Specify the NMS systems to receives the traps:

	[edit snmp v3]
	aviva@router1# set target-address nms2 address 192.168.15.27
	aviva@router1# set target-address nms2 tag-list config-trap-receivers
	aviva@router1# set target-address nms2 target-parameters nms2-parameters

Finally, configure which traps the NMS systems receive and the security used when sending the traps:

	[edit snmp v3]
	aviva@router1# set target-parameters nms2-parameters notify-filter config-traps
	aviva@router1# set target-parameters nms2-parameters parameters  
message-processing-
	model v3
	aviva@router1# set target-parameters nms2-parameters parameters security-model usm
	aviva@router1# set target-parameters nms2-parameters parameters security-level
	privacy
	aviva@router1# set target-parameters nms2-parameters parameters security-name nms2

Discussion

The configuration of SNMPv3 traps is much more involved than for SNMPv2, so let’s look at each step of the process. The first part of this recipe sets up traps for the objects related to the hardware chassis components.

First, configure a notification. SNMPv3 defines two types of notifications: informational and trap. You want to set type trap. You’ll also want to name the notification with the tag statement (here, chassis-trap-receivers) so that later in the configuration, you can associate the trap type with the NMS system that will be receiving the traps.

Second, create a filter that identifies which traps are sent to the NMS. Here, the filter named chassis-traps sends all traps from the Juniper chassis MIB.

Next, define the NMS systems to receive the trap notifications in the target-address statement hierarchy. Each target has a name, here nms1, which is the username of the NMS (also referred to as the security name). Then set the NMS system’s address and associate a tag list and security parameters with it. Here, we associate the chassis-trap-receivers tag and the nms1-parameters security parameters, which we define next.

Finally, associate a trap notification filter with the target NMS system (here, the chassis-traps filter) and define the security to use in all trap message exchanges. SNMPv3 security has three components: the message-processing model, the security model, and the security level. The processing model is SNMPv1, SNMPv2, or SNMPv3, which corresponds to the v1, v2, and v3 options of the message-processing-model statement. The security model is SNMPv1, SNMPv2, or USM, corresponding to the v1, v2c, and usm options of the security-model statement. Finally, the security level can be noAuthnoPriv, authNoPriv, or authPriv, which match the none, authentication, and privacy options of the security-level statement. Bundled in with defining the security parameters is the username (security name) of the receiving NMS system. Here, the security-name nms1 statement associates the security parameters with the system we defined in the target-address nms1 statement hierarchy.

Check the configuration using the show snmp v3 command. The following output shows only the portion related to the trap notifications:

	aviva@router1> show snmp v3
	SNMP Target:
	Address        Address         Port         Parameters     Storage      Status
	name                                        name           type
	nms1           10.0.10.1       162          nms1-parame    nonvolatile  active
	Parameters     Security        Security          Notify    Storage      Status
	name           name            model/level       filter    type
	nms1-parameter nms1             usm/privacy      chassis   nonvolatile  active
	SNMP Notify:
	Notify               Tag                Type                Storage      Status
	name                                                        type
	trap-notification-li NMS-trap-receiver  trap                nonvolatile  active
	Filter               Subtree            Filter              Storage      Status
	name                                    type                type
	chassis- 
traps        1.3.6.1.4.1.2636.  include             nonvolatile  active

The Target and Parameters portions of the output list the NMS systems configured to receive traps and lists the security parameters. The Notify and Filter portions give information about the traps that will be sent.

Here’s the traps portion of the SNMPv3 configuration file; you can see how all the pieces fit together:

	[edit snmp v3]
	target-address nms1 {
	    address 10.0.10.1;
	    tag-list NMS-trap-receivers;
	    target-parameters nms1-parameters;
	}
	target-address nms2 {
	    address 10.0.0.1;
	    tag-list config-trap-receivers;
	    target-parameters nms2-parameters;
	}
	target-parameters nms1-parameters {
	    parameters {
	         message-processing-model v3;
	         security-model usm;
	         security-level privacy;
	         security-name nms1;
	    }
	    notify-filter chassis-traps;
	}
	target-parameters nms2-parameters {
	    parameters {
	         message-processing-model v3;
	         security-model usm;
	         security-level privacy;
	         security-name nms2;
	    }
	    notify-filter config-traps;
	}
	notify chassis-notification-list {
	     type trap;
	     tag chassis-trap-receivers;
	}
	notify config-notification-list {
	     type trap;
	     tag config-trap-receivers;
	}
	notify-filter chassis-traps {
	     oid jnxChassisTraps include;
	     oid jnxChassisOKTraps include;
	}
	notify-filter config-traps {
	     oid jnxCmNotifications include;
	}

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required