Understanding SNMP

SNMP Commands

Instead of using a large set of commands to control network devices, SNMP uses the MIB database to do all of the work. Each controllable feature of the network device is allocated a record in the database. Controlling the feature is as simple as setting the proper value in the database. This means SNMP only has to worry about retrieving and setting database values, rather than having to interpret lots of individual commands to perform actions on the network device.

For example, instead of having a specific SNMP command to shut down a network interface on a device, the device contains a database record related to the state of the interface. If the record is set to a value representing an “off” condition, the device shuts down the interface. This allows any network management station to send an SNMP command to modify the database value and shut down the interface.

Using the MIB database reduces the complexity of the SNMP packets. Each SNMP command is called a protocol data unit (PDU). In SNMP version 1, there are only five types of PDUs that used to retrieve and set database values on network devices:

GetRequest The GetRequest PDU queries the remote SNMP device for a single data value in the MIB database.

GetNextRequest The GetNextRequest PDU queries the remote SNMP device for a series of data values starting at a specified point in the MIB. As each data value is returned, the next MIB object in the series is also returned to point the querying device to the next related object in the query. This enables an SNMP client to traverse an entire table of MIB database entries on the remote SNMP device.

GetResponse The GetResponse PDU returns the information that was requested in a GetRequest or GetNextRequest query.

SetRequest The SetRequest PDU attempts to set a value in the MIB database on the remote SNMP device. The sending device must have the proper access authority to write to the remote device MIB database.

Trap The Trap PDU sends an unsolicited data value to a remote SNMP management station. The Trap PDU is used for allowing devices to report error conditions automatically to a central management station on the network without having to be constantly queried.

Community Names

Because of the control that SNMP can have over a device, unauthorized users must be prevented from modifying a network device’s MIB database. SNMP provides a method of authentication through the community name system.

An SNMP application running on a network device contains an individual MIB database. A community name is the password that grants a particular access level to particular area in the MIB database (called a view). Community names can grant access levels to various MIB views. SNMP allows two access modes to the MIB database elements: read-only and read-write.

The pairing of an SNMP access mode with an SNMP MIB view is called a community profile. The pairing of a community name with a community profile is called an SNMP access policy. Many network devices allow you to create a large number of access policies, while some only allow two (one for reading the entire MIB database, and one for reading and writing to the entire MIB database).

The community name is defined as a byte string. There are no length limitations to the string. Two of the most popular community names (often used as default values on network devices) are public, for read-only access, and private, for read-write access. Obviously, if you are configuring an SNMP access policy on a network device, you will not want to use either of these well-known values.

Common Management Information Base

The Common MIB is the default standard database used for SNMP implementations on network devices. It is defined in RFC 1155 and provides for a set database format for network devices. Since its initial creation, a second version has been approved (MIB-II) and is used as the current standard.

MIB Structure

The MIB structure is one of the most confusing parts of SNMP. The MIB uses a treelike hierarchical database structure that defines data records as objects. Each object is referenced by an object identifier and has an object value.

The object identifier follows the Abstract Syntax Notation, version 1 (called ASN.1) naming convention. This standard syntax assigns a numerical value to each object and references objects in the tree based on a hierarchical naming convention. The naming convention is similar to the way DNS names are referenced, with dots separating name levels, except that for SNMP the root node is specified first.

For SNMP, the root object is named iso, for the International Organization for Standardization, and is assigned an object identifier of 1. All MIB entries are located under this object. The iso object contains a child node, named org, that can be referenced by name (iso.org) or by its object identifier (1.3). The third-level object, dod, has an object identifier of 1.3.6.

All of the MIB-II database entries are located under the internet object, which is a child node of the dod object and has an object identifier of 1.3.6.1.

You may see the official ASN.1 syntax name for objects in the MIB database. The ASN.1 syntax defines the object with the set of higher-level objects that it is derived from. Thus, for the internet object, the ASN.1 syntax is defined as follows:

internet ::= { iso(1) org(3) dod(6) 1 } 

This syntax defines the exact location of the internet object in the MIB database structure. The object can also be referenced by name, iso.org.dod.internet, but referencing the object identifier is much more common.

Note

The Internet Activities Board (IAB) is responsible for assigning all MIB object identifiers under the internet object.

Each child node under an object is assigned a unique object identifier. To reference an individual object, you must list each object identifier for each object level, starting at the top level. There are four child nodes located under the internet object, illustrated in Figure.

Figure: The iso.org.dod_.internet objects

As seen in Figure, the mgmt object contains the mib-2 object (1.3.6.1.2.1), which contains the MIB-II database objects. These mib-2 objects contain many network statistics objects, which allow you to query network devices for performance and monitoring. The mib-2 objects are listed in Figure.

Figure: The mib-2 Objects Used for Network Statistics

object	Node identifier	Description
System	1	System-specific values
Interfaces	2	Network interface statistics
At	3	Address translation table
Ip	4	IP statistics
Icmp	5	ICMP statistics
Tcp	6	TCP statistics
Udp	7	UDP statistics
Egp	8	EGP statistics
Transmission	10	Transmission statistics
Snmp	11	SNMP statistics

Each mib-2 object contains yet more child nodes that represent database values for the network device. For example, the system object contains the following objects:

sysDescr (1) A description of the network device

sysObjectID (2) A unique vendor identifier for the object

sysUpTime (3) The time since the network management portion of the system was initialized (in hundredths of a second)

sysContact (4) A point-of-contact for the network device

sysName (5) The administratively assigned name for the device

sysLocation (6) A descriptive location of the network device

sysServices (7) A value describing the services the device provides

Each system child node is assigned a unique node identifier (shown in parenthesis) and is referenced by the object identifier in ASN.1 syntax. For example, to see the system description of a network device, you would query for the 1.3.6.1.2.1.1.1 object identifier.

Note

When specifying an individual instance of an object in a GetRequest SNMP command, it is required that a trailing zero be placed at the end of the object identifier. This references the single instance value associated with the object. An instance of the sysDescr object would then be referenced as 1.3.6.1.2.1.1.1.0 in the GetRequest packet.