How To Use the Net-SNMP Tool Suite To Manage and Monitor Servers

Introduction

A large part of being a system administrator is collecting accurate information about your servers and infrastructure. There are a number of tools and options for gathering and processing this type of information. Many of them are built upon a technology called SNMP.

SNMP stands for simple network management protocol. It is a way that servers can share information about their current state, and also a channel through which an administer can modify pre-defined values. While the protocol itself is very simple, the structure of programs that implement SNMP can be very complex.

In previous guides, we discussed the basics of the SNMP protocol and how to install and configure SNMP components on Ubuntu 14.04 servers. In this guide, we will go over the basic usage of many of the tools that come with the net-snmp suite that we have been working with.

We will discuss how to leverage the configuration we set up in the last guide in order to actually gather information and manipulate remote hosts. This tutorial assumes that you have two hosts set up as they were at the end of the installation and configuration guide.

Using SNMP Client Commands

The net-snmp suite of tools that we have been using contains quite a few utilities that are useful for querying or setting OID values on remote hosts. Fortunately, most of the tools leverage a set of shared syntax and have similar usage patterns. We’ll go over the basic usage of some of the more popular ones below.

For the purposes of this guide, we are assuming that you are familiar with the authentication portion that you need to provide net-snmp commands. We are going to refer to all of the authentication information as authentication_info in the sections below.

If you have set up an snmp.conf configuration for your client as discussed here, you can remove this section of the command, as the authentication details will be read from your configuration file.

If you do not have an snmp.conf file, you will need to substitute the “authentication_info” in each command with the information needed to connect to your remote daemon. For the demo account that we set up in this series, the following values can be used:

-u demo -l authPriv -a MD5 -x DES -A my_new_password -X my_new_password

Substitute your own values when running these commands if you are in a different environment.

Now that you know the authentication details you will need, let’s get familiar with some of the commands available.

Retrieving Single OID Values with SnmpGet

This is probably the most basic command for querying information using SNMP. Using the basic authentication flags that were discussed earlier, the snmpget command can be used to read the value of any OID that the user has access to.

The basic usage is to specify a known numerical OID. For instance, we can retrieve the system description by typing:

snmpget authentication_info host 1.3.6.1.2.1.1.1.0

Since we installed the snmp-mibs-downloader package on our manager computer in the last guide, we can also reference common OIDs by their name. For instance, we could get the same information by typing:

snmpget authentication_info host sysDescr.0

Retrieving the Next Available OID Value with SnmpGetNext

This command is used to get the value of the OID after the one given. Since the MIB database is a walkable hierarchy, its values can be retrieved sequentially. By leveraging this property, we can find out the value (and the OID label) for the next object from any object in the tree.

For instance, we saw above how to get the system description. To find out the next OID and its value, we can call the same command, but this time with the snmpgetnext command:

snmpgetnext authentication_info host sysDescr.0

SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

This returns the system ObjectID, which is the next sequential object in the tree. We can repeat this over and over using the returned OID to get each sequential object:

snmpgetnext authentication_info host sysObjectID.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (114216) 0:19:02.16

These can use the string OIDs or the numeric OIDs, just like before.

Using SnmpWalk to Retrieve a Section of the MIB Hierarchy

To get all of the OIDs under a specified OID, you can use the snmpwalk command. This will return the entire tree that exists beneath the specified point.

For instance, we can get all of the values in the system portion of the tree by typing:

snmpwalk authentication_info host system

SNMPv2-MIB::sysDescr.0 = STRING: Linux target 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (126926) 0:21:09.26
SNMPv2-MIB::sysContact.0 = STRING: admin@example.com
SNMPv2-MIB::sysName.0 = STRING: target
SNMPv2-MIB::sysLocation.0 = STRING: Sitting on the Dock of the Bay
SNMPv2-MIB::sysServices.0 = INTEGER: 72
. . .

This command operates by automatically issuing SNMP getNext requests to the host until it can construct the entire tree beneath the value requested.

If you wish to retrieve basically the entire MIB tree, you can issue the command on the root:

snmpwalk authentication_info host .

This will return the entire tree that is accessible to the user provided.

This can be used, along with grep to search for specific OID names. For instance, you may know that the sysUpTime.0 OID returns the length of the that the SNMP daemon has been operational on the remote hosts, but you may be curious as to how long the server itself has been online.

We can use the snmpwalk command to get the entire hierarchy of OIDs and then filter it with grep to look for anything that has “uptime” in the name. We will use the -i flag to turn off case sensitivity in our search:

snmpwalk authentication_info host . | grep -i uptime

You will receive a response that looks like this:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (113856) 0:18:58.56
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.2 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.3 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.4 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.5 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.6 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.7 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.8 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.9 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORUpTime.10 = Timeticks: (0) 0:00:00.00
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (9741455) 1 day, 3:03:34.55
NOTIFICATION-LOG-MIB::nlmLogVariableID."default".1.1 = OID: DISMAN-EVENT-MIB::sysUpTimeInstance
NET-SNMP-AGENT-MIB::nsModuleName."".8.1.3.6.1.2.1.1.3.127 = STRING: mibII/sysUpTime

After trying a few of these values, we can find out that hrSystemUptime.0 OID contains the correct uptime value. Now, anytime we want to how long it’s been since that machine has booted, we can use that OID:

snmpget authentication_info host hrSystemUptime.0

HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (9795352) 1 day, 3:12:33.52

As you can see, snmpwalk can be very helpful for discovering the correct OIDs for values.

Translate Between Numeric and String OIDs with SnmpTranslate

One of the most helpful commands in the suite does not actually communicate with the remote host. Instead, it simply helps us discover information about the MIB hierarchy.

Using the snmptranslate utility, we can easily convert numeric results to their textual representation:

snmptranslate 1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0

This gives the MIB module that defines the textual name, and the name for the OID itself.

We can also use the tool to translate in the other direction. When we found out the textual MIB for the system’s uptime (hrSystemUptime.0), we might have been curious as to where on the tree that was defined. We could pass the -On flag to get the numerical address.

Remember to include the MIB module that is given whenever you receive information about an OID:

snmptranslate -On HOST-RESOURCES-MIB::hrSystemUptime.0

.1.3.6.1.2.1.25.1.1.0

You can also use this tool to get a lot of other detailed information about any point. For instance, with the -Td flag, you can get a full description, complete with the path at the bottom:

snmptranslate -Tp 1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0
sysDescr OBJECT-TYPE
  -- FROM	SNMPv2-MIB
  -- TEXTUAL CONVENTION DisplayString
  SYNTAX	OCTET STRING (0..255) 
  DISPLAY-HINT	"255a"
  MAX-ACCESS	read-only
  STATUS	current
  DESCRIPTION	"A textual description of the entity.  This value should
            include the full name and version identification of
            the system's hardware type, software operating-system,
            and networking software."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) sysDescr(1) 0 }

You can modify how the output is displayed by passing an -O_ parameter, where the “_” is replaced by an output format. You can see the full list in the “OUTPUT OPTIONS” section of the snmpcmd man page, but some of the more common choices are:

Note that the above formatting options can also be applied with most of the other tools in this suite to format the output how you would like.

Retrieve Tabular Data with Formatted Output with SnmpTable

Some information stored withing SNMP is actually tabular. Although snmpwalk has the ability to display all of the relevant data, the formatting is not ideal for some uses.

For instance, if we use snmpwalk on the udpTable OID:

snmpwalk authentication_info host udpTable

We would get this:

UDP-MIB::udpLocalAddress.0.0.0.0.161 = IpAddress: 0.0.0.0
UDP-MIB::udpLocalAddress.0.0.0.0.35679 = IpAddress: 0.0.0.0
UDP-MIB::udpLocalPort.0.0.0.0.161 = INTEGER: 161
UDP-MIB::udpLocalPort.0.0.0.0.35679 = INTEGER: 35679

However, if we make the same request with snmptable:

snmptable authentication_info host udpTable

We would get a nicely formatted table, like this:

 udpLocalAddress udpLocalPort
         0.0.0.0          161
         0.0.0.0        35679

This is much nicer formatting and easier to consume for a human reader.

Modifying Values with SnmpSet

This command is used to write the value to an OID. While the other commands so far were used to get information, this command is used to modify data on the host.

While the snmpset command inherits most of its syntax from the other commands, it requires some additional information to set the values. The basic syntax looks like this:

snmpset authentication_info host OID_to_modify data_type new_value

Most of the fields above are rather self-explanatory. However, the data types demand a bit more explanation. Each type is represented by a single character. The list of possible types is below:

• i: Integer
• u: Unsigned integer
• s: String
• x: Hexadecimal string
• d: Decimal string
• n: Null object
• o: Object ID
• t: Time ticks
• a: IP Address
• b: Bits

Since we have downloaded the snmp-mibs-downloader package, most of the time you can get away with typing = instead of one of the type identifiers.

To demonstrate this command, we can comment out one of the values set in our snmpd.conf file on the agent computer. Specifying values in the configuration file essentially hard-codes it, preventing you from changing the value using normal SNMP methods.

On the agent computer, open the /etc/snmp/snmpd.conf file:

sudo nano /etc/snmp/snmpd.conf

Comment out the sysLocation directive:

#sysLocation  Sitting on the Dock of the Bay

Save and close the file. Now restart the service:

sudo service snmpd restart

Now, from our management machine, we can set the sysLocation OID to “Earth” by typing this. Note the “s” that specifies that the data type is a string:

snmpset authentication_info host sysLocation.0 s "Earth"

SNMPv2-MIB::sysLocation.0 = STRING: Earth

We can test whether the = type specifier will correctly set the value type by refining our location:

snmpset authentication_info host sysLocation.0 = "New York City"

SNMPv2-MIB::sysLocation.0 = STRING: New York City

It has correctly interpreted our value as a regular string.

Issuing Requests Efficiently with SnmpBulkGet and SnmpBulkWalk

Issuing repeated snmpget and snmpwalk requests can create quite a lot of network traffic when used repeatedly.

To cut back on this problem, two companion commands called snmpbulkget and snmpbulkwalk were created. These will pack all of the return values within a single transaction rather than a transaction for each of returned OID value. You can also pass in more than one OID at a time.

To use snmpbulkget, you pass in one or more OIDs or branches and you will get back as many values for additional OIDs as fit in the packet:

snmpbulkget authentication_info host system

SNMPv2-MIB::sysDescr.0 = STRING: Linux target 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (429891) 1:11:38.91
SNMPv2-MIB::sysContact.0 = STRING: call now
SNMPv2-MIB::sysName.0 = STRING: target
SNMPv2-MIB::sysLocation.0 = STRING: New York City
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance

One thing to note is that snmpbulkget operates like a snmpgetnext command, meaning it that it leaves out the object given as an argument. In the above example, instead of supplying a specific object, we supplied a branch. You can think of snmpbulkget as an snmpwalk call, but the results will be in one packet.

The snmpbulkwalk command operates in a similar way, but will continue to make BulkGet commands until the entire subtree is retrieved.

Conclusion

As you can see, using the net-snmp suite, you can retrieve and manipulate data in a variety of ways. By scripting these actions or leveraging these utilities in applications, you can build complex monitoring and management environments.