Author: Brian Jones
term. To the uninitiated, raw SNMP output, along with arcane technobabble like
“MIB” and “ASN.1,” looks a little daunting. Developing some understanding of how
to parse and filter SNMP information doesn’t take long, though, and can put you on a
fast track to making SNMP bend to your whim.
The first thing to know about SNMP is that it is a service that is structured
such that an SNMP agent sitting on a target host can be queried by remote hosts
for various bits of information. Only the target host (the one you want
information about) needs to be running an SNMP daemon. The client making the
queries just needs some tool capable of making SNMP queries and parsing the
output. Most Linux server and client tools are supplied by
the Net-SNMP project. A quick poke around
your system to locate snmpwalk or snmpget should let
you know in short order if you have the client tools installed. The server
daemon is called, predictably, snmpd.
The easiest way to get familiar with how SNMP works is to set it up
on your own Linux system. Since this might be the piece of machinery with which
you are also the most familiar, it’ll also be a great way to see the sheer
power of SNMP. Since most Linux distributions come with a Net-SNMP daemon, I’m
going to forgo discussing installation and head right to configuration.
Configuring snmpd
If you maintain a lot of services, you’re probably tired of having to
remember which directive handles what in all of the differently formatted
config files. Apache, BIND, Sendmail, LDAP, NIS, NFS, and SSH all have
different formats — and that’s just the beginning. You’ll be relieved to know
that SNMP has a really great configuration tool called
snmpconf. Veteran sysadmins will be happy to know that this is a command-line
tool. New admins will have to suck it up!
Seriously, though, if you just want to get a very quick configuration put
together, try running snmpconf -g basic_setup, and you’ll be able
to set up what you need in order to see what the daemon has to offer. For those who have
more than three minutes on their hands and want more control over the
configuration, simply running snmpconf will prompt you with menus
to configure the different aspects of the running daemon. The questions are
very easy and completely self-explanatory (I’d even venture to say
elementary) for any Linux or Unix sysadmin. Once you finish, move the
resulting snmpd.conf file into place, and start the snmpd daemon.
Once the daemon is started, try pasting this into your terminal and pressing Enter: snmpwalk -v2c -c public localhost tcp. Here’s
some output from my laptop:
TCP-MIB::tcpConnState.0.0.0.0.22.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.111.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.199.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.0.0.0.0.32768.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.25.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.631.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.32769.0.0.0.0.0 = INTEGER: listen(2)
TCP-MIB::tcpConnState.127.0.0.1.32776.127.0.0.1.631 = INTEGER: closeWait(8)
This is just a chunk of output, and as you can probably discern, it’s
telling me which ports I have open (they’re in state “listen”). For
the record, recent Net-SNMP packages come with a command called
snmpnetstat that does this and more for you. But the point is that SNMP can tell
you just about anything you want to know about the running system, but
this output doesn’t reveal very much about SNMP itself.
Let’s alter the command like this: snmpwalk -On -v2c -c public localhost tcp. The -On flag tells the client to return the numeric OID or object ID
string instead of abbreviating it using the MIB used to parse said OID. What’s
an OID? Glad you asked. Let’s look at the output:
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.22.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.111.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.199.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.0.0.0.0.32768.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.25.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.631.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.32769.0.0.0.0.0 = INTEGER: listen(2)
.1.3.6.1.2.1.6.13.1.1.127.0.0.1.32776.127.0.0.1.631 = INTEGER: closeWait(8)
My favorite output flag, though, is -Of, which parses each of the
numbers above into a human-readable (if very long) name.
The OID in the above output is everything before the equals-sign. It’s called an
object ID because SNMP stores every piece of data as an object. Furthermore,
those objects are identified internally as numbers, which get parsed into names
on the client side, using a Management Information Base (MIB) file. A MIB
is a human-readable text file which is actually extremely handy, since it
contains all of the descriptions for the different pieces of data returned. If
you’re not sure if a particular piece of data is what you’re looking for,
heading for the MIB file that parsed it is usually a good way to find the
answer.
For example, in the first output listing, you can see something called
“tcpConnState.” At the very beginning of each line, you also see “TCP-MIB.” If
you want to see a better description of what this value really means, you need
to find a file on your system called TCP-MIB.txt; on my Fedora Core 2 machine, MIBs are in
/usr/share/snmp/mibs. grep for “tcpConnState” in the file,
and scroll down to the description to see what it says. NOTE:
Descriptions aren’t always useful. Generally, though, the standard MIBs (i.e.,
not vendor-supplied ones) are good enough to get a clue.
So what’s with the long numbers as OIDs? That’s ASN.1 notation. Abstract
Syntax Notation provides a standard way of describing data independent of
any language or application. Agents are written to provide data using ASN.1,
and client applications are written to handle that data in any
language and in any way the developers see fit. The goal is generalization, and
it would appear that it works. LDAP and SNMP both use ASN.1
notation, and the tools built around these two protocols (snmpwalk, ldapsearch,
etc.) handle the task of making the output readable by humans. In LDAP parlance,
a MIB is called a “schema.” The rest is very similar from a data representation
perspective.
For SNMP data (as well as LDAP), the ASN.1 numbers actually represent a
hierarchical structure — similar to the way the directory on your system is
hierarchical in nature. In fact, you could look at the numeric output above,
and think of .1 as the / or root directory. The fact that it’s followed
by a 3 would seem to imply that there are at least two other nodes under that
top-level node, and you’d be right in assuming that. The same goes for all of
the numbers all the way down the line. In fact, you could think of the command
snmpwalk -Of -v2c -c public localhost tcp as simply running
ls -lR on the tcp directory within the hierarchy.
What SNMP can do for you
Here are some quick one-liners that illustrate some cool stuff about your
system. These were tested on my FC2 laptop, as well as a SUSE 9.1 workstation:
snmpwalk -Ov -OQ -v2c -c public localhost
.1.3.6.1.2.1.25.6.3.1.2This lists the names of every installed package on the machine. It
essentially does the same thing asrpm -qaon an RPM-based distro,
but it’s slightly easier to grab the information from a remote location using
SNMP. There are lots of those-Oflags available. TheOstands for
“output,” and you can stack them as I’ve done here in order to strip out
everything but the actual value. For more on this, see thesnmpcmd
manpage.snmpwalk -Of -v2c -c public localhost interfaces | grep ".2 ="This walks the interfaces directory and grabs anything pertaining to
what amounts to “interface 2.” The interfaces are indexed numerically, and
interface 1 is generally the loopback. For each interface, a host of values is
displayed, so if you run something like this on a huge switch and aggregate and
parse the data, you can create some extremely useful data.- snmpwalk -OQ -Ov -v2c -c public localhost .1.3.6.1.2.1.25.4.2.1.2
This gets you a quick list of the programs running on a remote (or in this
case, a local) host. The processes are also indexed, and you can get other
information about them if you want to do a little scripting.Plenty more where this came from
This is the tip of the iceberg. For avid scripters, I’ve used both the Perl and
PHP SNMP interfaces, and both are immensely useful. Also, don’t think
that SNMP is limited in use to Linux boxen; SNMP agents have been
written for everything from large UPS units to tiny humidity sensors that’ll
send a trap if your machine room starts to resemble a swampland. If there’s
something in your environment with an Ethernet jack on it, there’s probably an
SNMP agent for it.I haven’t even mentioned the notion of actually making configuration changes via the
snmpsetcommand, but I urge you to investigate it for yourself. There’s a
whole SNMP world out there waiting for you, and taking advantage of it can make
your life as an administrator infinitely easier.
