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 calledSNMP.
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.
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_infohost 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_infohost 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 snmpgetnextcommand:
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:
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_infohost 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_infohost .
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:
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:
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:
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:
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:
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 oursnmpd.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_infohost 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_infohost 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 andsnmpbulkwalk 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_infohost 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 ansnmpwalk call, but the results will be in one packet.
The snmpbulkwalk command operates in a similar way, but will continue to make BulkGetcommands 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.
Paul Balo is the founder of TechBooky and a highly skilled wireless communications professional with a strong background in cloud computing, offering extensive experience in designing, implementing, and managing wireless communication systems.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behaviour or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
