Getting SNMP Data
Command Line vs Graphical Tools
To get SNMP data from your devices you can use command line tools or graphical tools.
In the category of graphical tools, there are a number of different options. Searching for "SNMP browser" in Google or your favorite search engine will turn up a number of options, some free and some paid.
Most Linux distros have command line SNMP tools built-in by default or they are easily installed using the distro's package manager. For Windows, we recommend downloading the Net-SNMP set of tools which can be found at http://www.net-snmp.org. All recent versions of MacOS come with command line SNMP tools installed by default.
Most graphical SNMP browsers use the standard command line tools under the hood so the examples in this ebook will use the command line tools as well.
By understanding how the command line versions work you will get a better understanding of how the SNMP protocol works and what options are available for it.
Using "snmpget"
The first command line tool you want to become familiar with is called "snmpget". This tool is used to retrieve values from a device and display them on the command line.
Let's use snmpget to retrieve the system name for a device by opening a command line window and running the following command:
snmpget -v 1 -c public 10.0.1.1 1.3.6.1.2.1.1.0
In the above example, the -v parameter tells snmpget to use SNMPv1 and the -c parameter tells it to use "public" for the community string.
Following the community string is the IP address of the device to query and lastly, we have the OID whose value we want to retrieve.
Running the above command should result in something like the following output:
SNMPv2-MIB::sysName.0 = STRING: My Router
As you can see, the snmpget tool found the value we asked for. It not only found it but also detected that the value was a string type and it gave us the string value which is "My Router".
In our example, we used the numeric OID but we could have used the symbolic name instead. Here is how the command looks using the symbolic name for the same value:
snmpget -v 1 -c public 10.0.1.1 SNMPv2-MIB::sysName.0
Since the symbolic name and the numeric OID refer to the same value, the output from this command is exactly the same:
SNMPv2-MIB::sysName.0 = STRING: My Router
You can easily get other values. Below is an example of how to get the system's description, which is a longer value that tells us a bit more about the device. This example and the ones that follow in this ebook will show both the command and the resulting output:
command:
snmpget -v 1 -c public 10.0.1.1 SNMPv2-MIB::sysDescr.0
result:
SNMPv2-MIB::sysDescr.0 = STRING: Demo Router in Lab 4
As with the system name, the snmpget command reported that it found a string value, this case "Demo Router in Lab 4".
Getting Multiple Values
In the above examples, we showed you how to use snmpget to retrieve a single value. You can also use snmpget to retrieve multiple values by including more OIDs or symbolic values after the first one.
For example, this will retrieve the system and description in one command:
command:
snmpget -v 1 -c public 10.0.1.1 SNMPv2-MIB::sysName.0 SNMPv2-MIB::sysDescr.0
result:
SNMPv2-MIB::sysName.0 = STRING: My Router
SNMPv2-MIB::sysDescr.0 = STRING: Demo Router in Lab 4
Lists of Values
In the previous section we showed you how to get multiple values using snmpget, but the assumption was that you already knew which individual values you were looking for.
Of course, there are some cases where you don't know in advance which values are available in the first place.
For example, although a switch or a router might have a fixed set of physical interfaces where you can connect network cables, almost all switches also have support for what are called virtual interfaces.
Virtual interfaces have many different uses and applications in the world of networking but, for the purposes of this ebook, the most important thing to know is that the total number of interfaces on a device might not correspond to the number of interfaces that are physically present on the hardware.
To give some context to this, look at the following snmpget command which retrieves the description for one interface:
command:
snmpget -v 1 -c public 10.0.1.1 IF-MIB::ifDescr.1
result:
IF-MIB::ifDescr.1 = STRING: eth0
In the above example, we asked for the description for the first interface (as defined by the .1 at the end of the symbolic name) and snmpget returned "eth0".
To get the name of the next interface, we can use this snmpget command which uses .2 in the symbolic name:
command:
snmpget -v 1 -c public 10.0.1.1 IF-MIB::ifDescr.2
result:
IF-MIB::ifDescr.3 = STRING: itf0
The problem is that we don't know how many interfaces the device has. We can guess based on the number of ports on the device but the number of virtual interfaces is unknown.
Of course we could just keep trying "ifDescr.3", "ifDescr.4", etc., until we stop getting results, but that doesn't sound like a very efficient approach.
Instead, we can use a different SNMP tool called "snmpwalk".
Using "snmpwalk"
The snmpwalk tool solves the problem of finding values when you don't know exactly how many are present. It can even be used to scan an unknown device and find the complete list of values it supports. In this section, we'll show you how to achieve both of these goals, but first, we'll look at the syntax and options used with snmpwalk.
The syntax of the snmpget and snmpwalk commands can be confusingly similar but with experience, you will gain familiarity with both.
Compare the following snmpwalk example with the ones provided earlier for snmpget:
command:snmpwalk -v 1 -c public 10.0.1.1 1.3.6.1.2.1.1result:SNMPv2-MIB::sysDescr.0 = STRING: Demo Router in Lab 4
SNMPv2-MIB::sysContact.0 = STRING: Network Admin
SNMPv2-MIB::sysName.0 = STRING: My Router
SNMPv2-MIB::sysLocation.0 = STRING: Main Office
SNMPv2-MIB::sysServices.0 = INTEGER: 14
The command is almost the same but the meaning of the last parameter is different. With snmpget, the last value you specify is the exact OID or symbolic name of the value you want to retrieve. With snmpwalk the last parameter is instead a starting point where the utility should begin looking for values.
As you can see in the result, snmpwalk returned a list of items showing both the symbolic name and the associated value for each.
Most SNMP-enabled devices make hundreds and sometimes thousands of values available for monitoring. In the above example, we saw that just 5 values were returned.
That's because we used a fairly specific starting point. The OID 1.3.6.1.2.1.1 specifies the base of the "system" section so that's why we see only those values.
If we use a more general starting point, we get more values:
command:snmpwalk -v 1 -c public 10.0.1.1 1.3.6.1.2.1result:SNMPv2-MIB::sysDescr.0 = STRING: Demo Router in Lab 4
SNMPv2-MIB::sysContact.0 = STRING: Network Admin
SNMPv2-MIB::sysName.0 = STRING: My Router
SNMPv2-MIB::sysLocation.0 = STRING: Main Office
SNMPv2-MIB::sysServices.0 = INTEGER: 14IF-MIB::ifPhysAddress.1 = STRING:
IF-MIB::ifPhysAddress.2 = STRING: 44:d9:e7:7:40:68
IF-MIB::ifPhysAddress.3 = STRING:
IF-MIB::ifPhysAddress.4 = STRING: 44:d9:e7:7:40:62
IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
IF-MIB::ifAdminStatus.4 = INTEGER: up(1)...
We've truncated the output to just 14 entries but on our test device, a total of about 2000 items were returned.
If you want to get all values that the device supports then you can leave out the last parameter as shown in this example:
command:snmpwalk -v 1 -c public 10.0.1.1
As you can see, snmpwalk provides a great mechanism to see what values a device supports. The length of the starting point you specify allows you to select how specific you want to be.
When running an snmpwalk command, it's often useful to redirect the output to a text file. The following example shows how to accomplish this:
command:snmpwalk -v 1 -c public 10.0.1.1 > output.txt
After the above command has finished running, the complete results will be stored in the output.txt file which you can view using your preferred text editor.
Most of the time, snmpwalk will be able to use its default set of MIB files to translate the number OIDs it finds into more readable symbolic names.
When it can't you will instead see full or partial number OIDS listed.
Here is an example of a part OID:
SNMPv2-SMI::mib-2.3.1.1.1.11.1.10.77.251.4 = INTEGER: 11
Based on the first portion of the OID, snmpwalk was able to determine that it is part of the SNMPv2-SMI::mib-2 set of OIDs but could not be more specific. This is because the MIB file(s) required for further translation were not present.
Sometimes full numeric OIDs might be returned as shown in this example:
.1.3.6.1.2.1.4.31.3.1.30.2.11 = Counter32: 90659
If the required MIB files were present then snmpwalk would be able to return this instead:
IP-MIB::ipIfStatsOutTransmits.ipv6.11 = Counter32: 90659
Without the MIBs, all we have to work with is a string of numbers. With the MIBs, we get enough information in the symbolic name to better understand what we are looking at.
The "ipIfStats" portion suggests that the value is related to TCP/IP interface statistics. The portion that reads "OutTransmits" suggests that this is a value counting the number of outgoing transmissions. The last portion "ipv6.11" tells us it's related to IPv6 networking and the counter is for the interface with index 11.
Armed with the MIB files we can get even more detail. Recall that MIB files are just text files so you can view them with any text editor. If you search for and download the IP-MIB file and search for "ipIfStatsOutTransmits" you will find the following description of the value:
ipIfStatsOutTransmits OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of IP datagrams that this entity supplied to the lower layers for transmission.
This includes datagrams generated locally and those forwarded by this entity.
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of ipIfStatsDiscontinuityTime."
Using the MIB file we now have a complete understanding of the counter's meaning and even information about another value that is related to its use.
As you have seen, MIB files can help substantially to interpret the results that you get from snmpwalk.
Whenever you are dealing with a new piece of hardware, visit the support section of the manufacturer's website. There you will find the MIB files for the device.
Most versions of snmpwalk will look for MIB files in a folder called "MIBS" which is either located under the folder where the snmpwalk is located or at another location defined by a command line environment variable.
If you don't see a MIBs folder, check the documentation for the toolset that you are using and follow the instructions provided there.
Next Chapter: SNMP VersionsTable of Contents
