6.2 Configuring SNMP on a Juniper Networks Router

Now that you have an understanding of how SNMP operates and what it was designed to do, let's discuss how to configure and enable SNMP on a Juniper Networks router. The following are the default conditions for SNMP defined by Juniper Networks that will guide the configuration process:

• SNMP is disabled.

• When SNMP is enabled, it is activated on all router interfaces.

• SNMPv1 and v2 are supported, and both are automatically activated, unless a version is specified.

• Read-write SNMP communities are not really writeable .

• The only time you can use an SNMP set command is through the use of the proxy ping set command (JUNOS 5.0 and later).

• Juniper Networks implementation of SNMP traps will transmit multiple traps (i.e., one for each version) if the version to use it is not specified.

• If the SNMP passwords are known, anyone can get information from a Juniper Networks router.

Activating SNMP is rather straightforward as SNMP has its own configuration hierarchy level; thus, all configuration statements will be made within the [edit SNMP] level. In a Juniper Networks router, there are a large number of optional parameters that can be used when configuring SNMP as listed below:

 [edit SNMP]  snmp {   description description;   location location;   contact contact;   interface [ interface-name ];   community community-name {     authorization authorization;     clients {       default restrict;       address <restrict>;     }     view view-name;   }   trap-group group-name {     categories category;     targets {       address;     }     version version;   }   view view-name {     oid object-identifier (include  exclude);   }   traceoptions {     file <files number> <size size>;     flag flag <disable>;   } } 

It is beyond the scope of this chapter to discuss all these parameters, but we will look at enough of these options for you to get SNMP operating on a complex internetwork. If additional information is needed, refer to the appropriate RFC or the resources recommended in the bibliography, such as the Juniper Networks documentation.

6.2.1 Basic SNMP Configuration

When configuring SNMP, there are two possible types of access to data that you must configure. In SNMP, access types are referenced as read-only and read-write.

 [edit snmp]  user@Chicago# set ? Possible completions: + apply-groups         Groups from which to inherit config data > community            Configure a community string   contact              Contact information for administrator   description          System description + interface            Restrict SNMP requests to interfaces   location             Physical location of system > traceoptions         Trace options for SNMP > trap-group           Configure traps and notifications > view                 Define MIB views 

It is also recommended that you configure the descriptive properties of SNMP as well (e.g., location, description, and contact). This provides network operation personnel with important information about who to contact if necessary.

 [edit snmp]  user@Chicago# set location "CHICAGO, NC" user@Chicago# set description "JUNIPER NETWORKS ROUTER" user@Chicago# set contact "TOM THOMAS" 

When dealing with SNMP communities (read-only and read-write), you must configure a password known to access the appropriate community. Note well that community strings are passwords and should be treated as such. In the following example, the router is configured to provide read-only access to those that provide the password public and read-write access to those who possess the password 800frIP .

 [edit snmp]  user@Chicago# set community public authorization read-only [edit snmp] user@Chicago# set community 800frIP authorization read-write 

The completed initial SNMP configuration looks as follows :

 [edit snmp]  user@Chicago# show description "JUNIPER NETWORKS ROUTER"; location "CHICAGO, NC"; contact "TOM THOMAS"; community public {     authorization read-only; } community 800frIP {     authorization read-write; } 

Now that the initial SNMP configuration has been completed, you need to test access and operation. Once you configure the MIB browser with the proper password, you can access the router. Refer to Figure 6-6, where an SNMP query was sent to the router at 192.168.254.70 to retrieve the system description at the OID 1.3.6.1.2.1.1.1.0 .

Figure 6-6. Testing SNMP Access and Operation

6.2.2 Configuring SNMP Trap Groups

SNMP traps are the notifications used by SNMP to alert you to a problem or change in status within a device. Trap groups in SNMP are excellent tools that allow the distribution of certain specified traps to the devices that you indicate . The trap-group name field will be transmitted within every trap sent as identified in that trap group. When configuring a trap group, make sure that you specify a target , otherwise it will not be very effective. A possible configuration is shown below:

 [edit snmp]  user@Chicago# show description "JUNIPER NETWORKS ROUTER"; location "CHICAGO, NC"; contact "Tom Thomas"; community public {     authorization read-only; } community 800frIP {     authorization read-write; } trap-group ALERTS {     version v2;     categories link;     targets {         192.168.254.7;     } } [edit snmp] user@Chicago# 

Note

An SNMP trap group target is usually the IP Address of the SNMP server.

In addition to defining the target of a trap group, you can also specify which SNMP version of traps will be transmitted. By default, Juniper Networks routers will transmit all versions; thus, you may end up receiving multiple traps if you do not specify a version.

The NMS is configured to receive the link traps via the ALERT trap group. Link traps consist of reporting the up-down status of router interfaces. In Figure 6-7, the NMS receives two traps: The first trap is a link-down notification and tells who (router 192.168.254.70 ), what (link-down notification), where (interface fxp2 ), and when (10/27/01 ”11:19). The second trap notifies us that the interface is back up.

Figure 6-7. Link Down/LinkUp Trap Receipt

6.2.3 Controlling SNMP Access

There has been some confusion about SNMP access and Juniper Networks routers. Note that you cannot use the SNMP set command to change any value in a Juniper Networks router ”they are read-only. Keep this in mind when configuring SNMP on a Juniper Networks router as it is a key differentiator from other vendors and a deviation from the SNMP standard. In general then, we can say that SNMP access is always read-only, regardless of what the documentation or router tells you.

That a Juniper Networks router only supports read-only access does not mean you should allow just anyone to retrieve SNMP data from your router. You may want to reduce or limit the OIDs that a certain NMS or netblock has the ability to read on your routers. Say you only want to let customers read interface counters on the interfaces they are connected to, thus allowing them to see the performance of their connection. In this case, you would create an MIB VIEW associated with an SNMP community.

The following example creates a community called CUSTOMER and an MIB VIEW called CUSTOMER . When you assign that MIB VIEW to the community as shown in the configuration output below, you restrict access to the interface OIDs from the SNMP tree.

 [edit snmp]  user@Chicago# show description "JUNIPER NETWORKS ROUTER"; location "CHICAGO, NC"; contact "TOM THOMAS"; view CUSTOMER {     oid .1.3.6.1.2.1.2; } community public {     authorization read-only; } community 800frIP {     authorization read-write; } community CUSTOMER {     view CUSTOMER;     authorization read-only; } trap-group ALERTS {     version v2;     categories link;     targets {         192.168.254.7;     } } [edit snmp] 

It is important to note that the OID is inherited in Juniper Networks routers. Thus, the OID used here ( .1.3.6.1.2.1.2 ) is that for the interface group; all more specific OIDs beneath it are considered within it. In Figure 6-8, the interface group is selected and its OID used in the configuration example. Notice that all the interface characteristics and more specific entries beneath the interface group are accessible by default. Caution is required when determining which OIDs are accessible. For example, it may not be appropriate to allow a customer access to the MIBs, which contain all the routing data for your network.

Figure 6-8. OID Inheritance

6.2.4 Configuring the Interfaces on Which SNMP Requests Can Be Accepted

In today's world, many networks are extremely security conscious, and Juniper Networks has provided a method for changing the default behavior of accepting SNMP queries on any interface. You can specify the interface names that you want to allow to receive and process SNMP requests. This feature is configured by specifying the interface type at the [edit SNMP] configuration level in the JUNOS CLI, as shown below. If you wish to allow multiple interfaces access to SNMP, then put the names of the interfaces within brackets.

 [edit snmp]  interface [ interface-names ]; 

This example shows how combining MIB VIEWs and limiting interfaces increases the security of a Juniper Networks router. When we consider MIB VIEWs combined with the interface-limiting concept, the security of a Juniper Networks router is greatly increased.

One of the most common uses of by enabling SNMP on an interface is the presence of a separate network used only to manage network devices. In this case you would just enable SNMP on the interface connected to the dedicated management network.

6.2.5 Verifying Operation and Troubleshooting SNMP

SNMP failures in operation are not complex, and indications of it are rather easy to determine. The preceding sections showed how the ability to access and have traps reported is accomplished. SNMP failures or misconfigurations will cause this feature not to work, which, unlike a routing failure, can be extremely noticeable. In this section we will look at how to use the JUNOS trace options to track the operation of SNMP and to display SNMP statistics.

6.2.5.1 Trace Options

To trace SNMP traffic, you specify trace options by including the traceoptions statement at the [edit snmp] hierarchy level. As the following example shows, you can set the filename and size, among other things:

 [edit snmp]  user@Chicago# set traceoptions filename files 10 size 500 user@Chicago# set flag ? Possible completions:   all                  Trace everything   general              Trace general events   interface-stats      Trace interface statistics (logical and physical)   pdu                  Dump SNMP request/response packets   protocol-timeouts    Trace SNMP request timeouts   routing-socket       Trace routing socket calls   subagent             Trace Sub-agent restarts   timer                Trace internal timer events   varbind-error        Trace varbind errors [edit snmp traceoptions] user@Chicago# set flag all 

Using the all option would result in a configuration for SNMP that has tracing enabled as follows:

 [edit snmp]  user@Chicago# show description "JUNIPER NETWORKS ROUTER"; location "CHICAGO, NC"; contact "TOM THOMAS"; view CUSTOMER {     oid .1.3.6.1.2.1.2; } community public {     authorization read-only; } community 800frIP {     authorization read-write; } community CUSTOMER {     view CUSTOMER;     authorization read-only; } traceoptions {     file size 500 files 10;     flag all; } 

The output of the tracing operations is placed into the following three files, all of which are located in the /var/log directory, which is accessible via the shell:

• snmpd ” contains errors and communications between the server and subagents

• mib2d ” contains all interface statistics

• rmopd ” contains all ping MIB statistics

If you are interested in learning additional information on the trace options functionality and features, refer to Section 15.6.

6.2.5.2 SNMP Statistics

You can see the operation and function of SNMP via the following commands:

• show snmp statistics

• clear snmp statistics

This next example of the show command demonstrates the various parameters and statistics that you can recover from the statistics command:

 user@Chicago> show snmp statistics  SNMP statistics:   Input:     Packets: 0, 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: 0, Total set varbinds: 0,     Get requests: 0, Get nexts: 0, Set requests: 0,     Get responses: 0, Traps: 0,     Silent drops: 0, Proxy drops 0   Output:     Packets: 9, Too bigs: 0, No such names: 0,     Bad values: 0, General errors: 0,     Get requests: 0, Get nexts: 0, Set requests: 0,     Get responses: 0, Traps: 9 

The clear SNMP command resets all the values displayed back to zero. This is useful when troubleshooting or monitoring the operation of SNMP by resetting the values to zero.