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 clientserver 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.

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.