« If you want to really thank veterans | Main | A Roller Derby Fanboy Post »

Normally, I'd leave this as a comment, but wordpress is unhappy with logins or something.

So in this article, Charles talks about using SNMP to get network information for JAMF's Casper software, via shell scripting. (By the way JAMF guys: an SNMP console with a good UI would be a FANTASTIC addition to Casper. Most SNMP consoles kind of suck, UI-wise.)

First, nothing Charles talks about is incorrect, but it is somewhat inefficient, in terms of SNMP. It could be done better. So let's look at that.

The value that Charles is using in his example is uptime, which is part of the base SNMP support that you see in any device that supports SNMP. I've been beating on SNMP for years now, I've never seen anything that doesn't support sysUpTime. So, we can make some assumptions once we know the OID we need to query. As Charles recommends, we use snmpwalk for this. (A minor quibble: Charles queries using SNMP v1. In general, you should use version 2c if you aren't in an SNMP 3 environment. 2c is almost ubiquitous, and has larger counters, something of import for things like uptime. There are some v1 - only devices out there, but they're rare enough that assuming 2c until proven wrong is acceptable.)

So we'll do a quick snmpwalk to generate the OID values we need. To get this, we do two runs. The first returns the generic MIB descriptions, the second gives us the numerical OID values. (Note: if all this OID and MIB stuff is confusing, I have a long, but complete SNMP primer. If you are new to SNMP, you should read that first.)

The first command:
snmpwalk -v 2c -c public -m ALL localhost .1|more

This tells snmpwalk to query a v 2c device with a public community string of "public", using all available MIBs. The device its targeting in this case is itself, and it should start at the beginning of the OID tree, aka ".1". I pipe it to more, because running snmpwalk against a full MIB tree can crash snmpd, and in any case, what we're looking for is in the first page returned. The result we get is:

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (38246285) 4 days, 10:14:22.85 (this is on an Xserve)

So now that we know what we're looking for, let's re-run snmpwalk, only with the -On option, which gives us the numerical OID value for sysUpTime.

The second command: snmpwalk -v 2c -c public -m ALL -On localhost .1|more

This gives us the numerical OID value for sysUpTime:

.1.3.6.1.2.1.1.3.0 = Timeticks: (38248082) 4 days, 10:14:40.82

The nice thing about this particular value is that it's the same for an Xserve, an AEBS, or really, anything with even basic SNMP support. So now, instead of having to walk the SNMP tree, then parse out the one value you care about, then use that result, we can use snmpget to show us the result we want:

snmpget -v 2c -c public localhost .1.3.6.1.2.1.1.3.0

Which gives us:

SNMPv2-MIB::sysUpTime.0 = Timeticks: (38340865) 4 days, 10:30:08.65

However, that still leaves us a lot of data we don't care about, like the MIB identifier bit. We KNOW that, so we don't need it back. Therefore, we use the -Ov output option which prints values only, not the OID = value format:

snmpget -v 2c -c public -Ov localhost .1.3.6.1.2.1.1.3.0

Which returns:

Timeticks: (38348581) 4 days, 10:31:25.81

So that's a bit easier to parse, or at least less data to parse, and we don't have to deal with the overhead of snmpwalk. Actually, you can substitute snmpget for snmpwalk pretty easily in Charles' script. Change:

if [ "$COMPUTERNAME" = "$SERVER" ] ; then

     UPTIME=$( snmpwalk -v1 -c public -M /usr/share/snmp/mibs \

     -m AIRPORT-BASESTATION-3-MIB $AIRPORTIP | grep sysUpTime | cut -d \) -f 2 )

else

     UPTIME=""

fi

to:

if [ "$COMPUTERNAME" = "$SERVER" ] ; then

     UPTIME=$( snmpget -v 2c -c public $AIRPORTIP .1.3.6.1.2.1.1.3.0 | cut -d \) -f 2 )

else

     UPTIME=""

fi

(the mibs switches are somewhat unnecessary for snmpget. We know what we're going after, we don't need it explained to us. In general, MIBs are there to help the humans, they're not really needed for SNMP in and of itself.)

In

As a rule, when dealing with SNMP, try to only use snmpwalk to acquire info on the OID(s) you really want to use. For actual regular command use, snmpget and snmptable are better choices. Also, play a bit with the -O options in the SNMP command set. It can really help you narrow down the output so you don't have as much work to do.

Comments