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 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.
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.
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.
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.
You want to set the router up to be an SNMP agent so your network SNMPv2 NMS system can monitor the router.
Use the following commands to configure the router to be an SNMP agent:
[edit] aviva@router1#set snmp communitypublicauthorizationread-onlyaviva@router1#showsnmp { community public { authorization read-only; } }
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: 0The 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.
You need to define specific information about the router, such as its name and location, to pass to the SNMP manager.
Set description, location, and contact information about the router:
[edit snmp] aviva@router1#set description "aviva@router1#JUNOS cookbook M20, aka router1"set location "aviva@router1#JUNOS cookbook kitchen"set contact "aviva at extension 12345"
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-routerYou 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 publicsystem.sysDescr.0 = JUNOS cookbook M20, aka router1 aviva-server>router1system.sysDescrsnmpwalk -c publicsystem.sysContact.0 = aviva at extension 12345router1system.sysContact
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 = 4You can also look at a single MIB object:
aviva@router1> show
snmp mib get sysDescr.0
sysDescr.0 = JUNOS cookbook M20, aka router1In 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 = router1For this command to work, make sure to enclose the list of objects in quotation marks.
You want to create triggers on the router to send unsolicited notifications to the NMS system when a router event occurs.
Configure traps by setting up SNMP trap groups:
[edit snmp] aviva@router1#set trap-group authentication-traps targetsaviva@router1#10.0.10.1set trap-group authentication-traps targetsaviva@router1#192.168.15.27set trap-group authentication-traps categoriesauthentication
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
|
Type | ||
|---|---|---|
|
Standard |
Agent (router) authentication failures | |
|
Enterprise |
Chassis and router environment notifications | |
|
Enterprise |
Configuration mode notifications | |
|
Enterprise |
Link-related transitions, such as when hardware transitions from up to down, or vice versa | |
|
Enterprise |
RMON event alarms | |
|
Enterprise |
Routing protocol notifications | |
|
Enterprise |
SONET alarm notifications | |
|
Standard |
Router warm and full reboots | |
|
|
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 }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/32The second is to limit the router interfaces that can communicate with the NMS system:
[edit
snmp]
aviva@router1# set interface [fe-0/0/0]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 clientsaviva@router1#10.0.0.0/8set community public clients10.0.0.1/32restrict
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]The introduction to Chapter 7
You have a firewall filter on your interfaces and want to add a term to restrict NMS system access to the router.
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 filterprotect-RE term allow- snmp-from-nms-systems] aviva@router1#set from source-addressaviva@router1#10.0.0.1/32set from source-addressaviva@router1#10.0.5.1/32set from source-addressaviva@router1#10.0.6.1/34set from source-addressaviva@router1#10.10.1.50/32set from protocol udpaviva@router1#set from destination-port snmpaviva@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-REAn 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-meFashion 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 filteroutgoing-from-me] aviva@router1#set term allow- snmp-to-nms-systems source-port snmpaviva@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.
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.
Use the following commands to define the MIB branches that a community can access:
[edit snmp] aviva@router1#set viewaviva@router1#chassis-info-onlyoid jnxBoxAnatomy includeset viewaviva@router1#chassis-info-onlyoid snmpMIBObjects includeset viewchassis-info-onlyoid system include
Then associate the MIB view with the community:
[edit snmp]
aviva@router1#
set community chassis-access-only view chassis-info-onlyBy 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 viewaviva@router1#ping-traceroute-excludeoid jnxPingMIB excludeset viewaviva@router1#ping-traceroute-excludeoid jnxTraceRouteMIB excludeset communitypublicviewping-traceroute-exclude
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]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.
You want to use SNMP to find out router hardware information and which field-replaceable units (FRUs) are present in the router.
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 = jnxProductNameJ230M20To get information about the next router component in the MIB:
aviva@router1>show snmp mib getjnxBoxClass.0 = jnxProductLineM20.0 aviva@router1>jnxBoxClass.0show snmp mib get-nextjnxBoxDescr.0 = Juniper m20 Internet Backbone RouterjnxBoxClass.0
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.0To 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.0In 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.0jnxContentsType.9.1.0.0 = jnxM20RE.0 aviva@router1>show snmp mib get jnxContentsDescr.9.1.0.0jnxContentsDescr.9.1.0.0 = Routing Engine 0 aviva@router1>show snmp mib get jnxContentsSerialNo.9.1.0.0jnxContentsSerialNo.9.1.0.0 = 58000007348d9a01 aviva@router1>show snmp mib get jnxContentsRevision.9.1.0.0jnxContentsRevision.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, MMLook 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
…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-engineRouting 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 FDRAM 768 MBMemory 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 PSTUptime 4 days, 3 hours, 57 minutes, 35 secondsLoad averages: 1 minute 5 minute 15 minute 0.07 0.05 0.02
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.
Use the following command to log SNMP operations and NMS connections:
[edit snmp]
aviva@router1# set traceoptions flag pduYou 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.
You want to collect Juniper Networks enterprise-specific traps in the router’s system logging files.
Use the following commands to save all log messages to a file called snmp-critical-traps:
[edit] user@router1#edit system syslog file[edit system syslog filesnmp-critical-trapssnmp-critical-traps] user@router1#set daemoncritical
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 | |
|
Insertion of a replaceable chassis component | |
|
Powering down of a replaceable chassis component | |
|
Powering up of a replaceable chassis component | |
|
Removal of a replaceable chassis component | |
|
Critical | |
|
Chassis fan or impeller failure | |
|
Chassis fan or impeller recovery | |
|
Overheating of a hardware component | |
|
Power supply recovery | |
|
Chassis component has switched from master to backup, or vice versa | |
|
Alert | |
|
Power supply failure | |
|
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.
You want to use remote monitoring (RMON) to have the router monitor and proactively report on overtemperature conditions in the router.
Create an RMON trap that watches the internal temperature of the router by tracking the backplane temperature:
[edit snmp] aviva@router1#set trap-groupaviva@router1#overtemperatureset trap-groupaviva@router1#overtemperaturecategories rmon-alarmset trap-groupaviva@router1#overtemperaturetargets10.0.10.1edit rmon[edit snmp rmon] aviva@router1#set alarm 1 description "aviva@router1#overtemperature for M20 backplane"set alarm 1 intervalaviva@router1#300set alarm 1 variable jnxOperatingTemp.1.1.0.0aviva@router1#set alarm 1 sample-type absolute-valueaviva@router1#set alarm 1 rising-thresholdaviva@router1#40set alarm 1 startup-alarm rising-alarmaviva@router1#set alarm 1 rising-event-indexaviva@router1#1set event 1 description Heap-Eventsaviva@router1#set event 1 type log-and-trapaviva@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;
}
}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 thresholdThe 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 = 22You can also see it with the
show chassis environment command:
aviva@router1>show chassis environmentClass 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 FBackplane OK 22 degrees C / 71 degrees FRouting 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 trapWhen 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 = 1First, define the NMS systems that can access the router and their passwords:
[edit snmp v3] aviva@router1#set usm local-engine useraviva@router1#nms1authentication-sha authentication- password$1991poppIset usm local-engine usernms1privacy-des privacy-password$1991poppI
Then, define the MIBs to which the users have access:
[edit snmp] aviva@router1#set viewaviva@router1#chassis-info-onlyoid jnxBoxAnatomy includeset viewaviva@router1#chassis-info-onlyoid snmpMIBObjects includeset viewchassis-info-onlyoid 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-nameaviva@router1#nms1groupchassis-onlyset vacm access groupaviva@router1#chassis-onlydefault-context-prefix security- model usm security-level privacy read-viewchassis-info-onlyset vacm access groupchassis-onlydefault-context-prefix security- model usm security-level privacy notify-viewchassis-info-only
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-inThe 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;
}First, define the NMS system and its password:
[edit snmp v3] aviva@router1#set usm local-engine useraviva@router1#nms2authentication-sha authentication- password$0212roZHset usm local-engine usernms2privacy-des privacy-password0212roZH
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 includeThe second view sets what the router includes in notifications sent to the NMS:
[edit snmp v3] aviva@router1#set viewaviva@router1#config-info-notifyoid jnxCfgMgmt includeset viewaviva@router1#config-info-notifyoid jnxCmNotifications includeset viewaviva@router1#config-info-notifyoid snmpMIBObjects includeset viewconfig-info-notifyoid 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-nameaviva@router1#nms2groupconfig-onlyset vacm access groupaviva@router1#config-onlydefault-context-prefix security- model usm security-level privacy read-viewconfig-info-readset vacm access groupconfig-onlydefault-context-prefix security- model usm security-level privacy notify-viewconfig-info-notify
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;
}You want SNMPv3 to generate traps about chassis and configuration events and send the traps to the NMS system.
For the chassis events, first configure the trap notification:
[edit snmp v3] aviva@router1#set notifyaviva@router1#chassis-notification-listtype trapset notifychassis-notification-listtagchassis-trap-receivers
Next, define the traps to send:
[edit snmp v3] aviva@router1#set notify-filteraviva@router1#chassis- trapsoid jnxChassisTraps includeset notify-filterchassis-trapsoid jnxChassisOKTraps include
Identify the NMS systems (the targets) to receive the traps:
[edit snmp v3] aviva@router1#edit target-address[edit snmp v3 target-addressnms1nms1] aviva@router1#set addressaviva@router1#10.0.10.1set tag-listaviva@router1#chassis-trap-receiversset target-parametersnms1-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[edit snmp v3 target-parametersnms1-parametersnms1-parameters] aviva@router1#set parameters message-processing-modelaviva@router1#v3set parameters security-modelaviva@router1#usmset parameters security-levelaviva@router1#privacyset parameters security-nameaviva@router1#nms1set notify-filterchassis-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 notifyaviva@router1#config-notification-listtype trapset notifyconfig-notification-listtagconfig-trap-receivers
Next, define the trap to send:
[edit snmp v3]
aviva@router1# set notify-filter config-traps oid jnxCmNotifications includeSpecify the NMS systems to receives the traps:
[edit snmp v3] aviva@router1#set target-addressaviva@router1#nms2address192.168.15.27set target-addressaviva@router1#nms2tag-listconfig-trap-receiversset target-addressnms2target-parametersnms2-parameters
Finally, configure which traps the NMS systems receive and the security used when sending the traps:
[edit snmp v3] aviva@router1#set target-parametersaviva@router1#nms2-parametersnotify-filterconfig-trapsset target-parametersaviva@router1#nms2-parametersparameters message-processing- model v3set target-parametersaviva@router1#nms2-parametersparameters security-model usmset target-parametersaviva@router1#nms2-parametersparameters security-level privacyset target-parametersnms2-parametersparameters security-namenms2
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 activeThe 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;
}Get JUNOS Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
