enough SNMP to be dangerous, part 2

by Elizabeth Zwicky
<zwicky@greatcircle.com>

Elizabeth is technical lead of the European Desktop Project at Silicon Graphics. She was a founding member of SAGE and is currently on the USENIX Board of Directors.


This is the second in a series of articles dedicated to teaching typical UNIX system-administrator types — people who can compile public-domain software and have some idea about TCP/IP — how to do UNIX-style hackery with SNMP. It is not an elegant and systematic approach to SNMP, but it should give you enough background to be dangerous.

In part one (;login:, December 1998), we looked at system.sysDescr. This was an enlightening display of the inability of vendors — even vendors with a strong specialty in SNMP — to get extraordinarily simple parts of the specification correct. However, it's not all that amusing, so let's continue to explore MIB-II and its opportunities for stupid tricks. To look at a chunk of variables at the same time, instead of one, you can use snmpwalk where you previously used snmpget. To look at the values for everything in the system block, use

snmpwalk hostname public system

The system block of MIB-II offers the following variables:

      sysDescr
      sysObjectID
      sysUpTime
      sysContact
      sysName
      sysLocation
      sysServices

sysDescr we have already seen. sysObjectID is defined like this:

The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining "what kind of box" is being managed. For example, if vendor "Flintstones, Inc." was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its "Fred Router."

Quick translation: sysDescr is useless for most practical purposes. In particular, vendors shove random stuff into it so that two effectively identical machines have different sysDescrs (for instance, the sysDescr may contain the host name, annoyingly pointless since it occurs later on, or the exact second at which the kernel was compiled). sysObjectID will at least identify two boxes as being the same type — and it will also usually point you at a place in the tree where there is more information specific to the particular device. In practice, sysObjectID isn't all that useful either, since it generally is much too broad, and most of the truly interesting information is elsewhere. But if you get tired of doing vendor-specific text parsing of sysDescr, then sysObjectID is a useful hint.

sysContact and sysLocation are the person responsible for the device and the location of the device, respectively. These are almost always blank. If you have carefully set them on all your devices, you are much too advanced for stupid SNMP tricks.

sysName is the system name; the specification says, "By convention this is the fully-qualified domain name." Possibly so; but as you may be beginning to suspect, this is no guarantee. On UNIX machines, it's usually a fully or partially qualified domain name. On Microsoft machines, it's usually the machine's WINS (Microsoft-protocol) name. On other machines, things are considerably more fluid — it might be the name used in any old protocol, or a name hand-configured by the user, which results in fascinating slippage. (One of our local machines thinks it is named "octwan.cortiallod.sgi.com"; the configurer was trying to type "cortaillod," but actually the domain is named "neu," because "cortaillod" is too hard to type!) Thus, it's usually better to ignore sysName, too. Admittedly, only one of the machines I tested managed to produce a protocol error in sysName, by returning NULL instead of an empty string.

That leaves sysServices and sysUptime. sysServices, properly interpreted, will tell you which layers of the ISO stack the device is working at. I don't know about you, but I find this less than thrilling. sysUptime, on the other hand, is how long the network responder has been up, which is usually very closely related to the length of time the device has been up. This allows you to play amusing, if pointless, games to find out what device on your network has the best uptime.

Assuming you have a list of hosts, and they have SNMP responders started at boot, the following code will settle the uptime argument for once and for all (or at least until people start arguing about which devices count):

#!/usr/bin/perl5

use SNMP;

$SEC = 100; $MIN = 60 * $SEC; $HOUR = 60 * $MIN; $DAY = 24 * $HOUR;

while (<>) { # stdin is a list of hosts, one per line
      $hostname = chop;
      if ($sess = new SNMP::Session(DestHost=> "$hostname")){
          $time = $sess->get(["system.sysUptime", "0"]);
      }
      else {
          print "Error: could not bind $hostname\n";
      }
      $uptimes{$time} .= "$hostname ";
}

foreach $uptime (sort numerically keys %uptimes){
      $cutetime = &tformat("$uptime");
      print "$cutetime: $uptimes{$uptime}\n";
}

sub numerically {$b <=> $a;}

sub tformat {
      my($time) = @_;

      my($days) = int($time/$DAY);
      $time = $time - ($days * $DAY);

      my($hours) = int ($time/$HOUR);
      $time = $time - ($hours * $HOUR);

      my($minutes) = int ($time/$MIN);
      $time = $time - ($minutes * $MIN);

      my($seconds) = int ($time/$SEC);
      my($ticks) = $time - ($seconds * $SEC);

      return "$days days, $hours:$minutes:$seconds:$ticks";
}

Our local winner was:

    397 days, 7:47:2:98: mmac131l.neu

This is a smart hub, which is the sort of thing that starts people complaining that you really ought to limit the competitors to machines that run actual operating systems.

How do I know it's a smart hub? Not from system.sysDescr.0, which is "IRM2 SNMP Version 1.00.10", which means nothing to me. However, system.sysObjectID.0 is "enterprises.52". Being an enterprising person myself, I went to <ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers>, which told me that enterprise 52 is Cabletron. Doing a search on Cabletron's site showed me that the only place on the entire site that mentions "IRM2" is in fact the documentation for their SNMP management application. This starts out "The IRM2 (Intelligent Repeater Module) provides intelligence to a Cabletron Systems Multi Media Access Center (MMAC) and serves as an IEEE 802.3 repeater for the hub." This is one of the few situations where sysServices might have been useful; knowing that I was looking at a device that operated only at level 1 would have been a tip-off. However, the IRM2 doesn't provide sysServices. You also might have hoped for a sysObjectID more revealing than the top level node for Cabletron, but the IRM2 doesn't implement anything except the bare essentials of MIB-II.

Next: Getting practical — SNMP diagnostics for network problems.