Network Device Interrogation

SNMP is the universal protocol for monitoring network devices of all sizes. We look at SNMP's role and show you how to start gathering data.

Network Management is one of those things that Big Companies do. It’s a task often associated with hardware and software that costs six figures and requires lots of special training and experience to operate properly.

In the broadest context, Network Management is about the hardware, software, and techniques that are used for monitoring the health of your network and the devices connected to it. Typically, most smaller companies and people with home networks spend very little, if any, time thinking about these things — until a problem occurs.

That’s why a minimal level of management benefits even the smallest networks. On a small office local-area network (LAN) you may want to ask questions like, “Is the subnet served by the hub in the closet on the second floor congested?” and “How much traffic are we sending out through our Internet connection (and why is our provider charging for more)?” Or maybe, “Are any of our servers running low on memory or disk space?”

Equipped with a basic understanding of the Simple Network Management Protocol (SNMP) and the right software, you can begin to gather the data you’d need to answer those questions (and others like them). The SNMP Terms and Concepts sidebar, pg. 21, describes some of the terminology that we’ll encounter along the way.

SNMP’s History

During the mid-’80s, system and network administrators commonly used ping, traceroute, tcpdump, and similar command-line utilities to help keep traffic flowing over their networks. These tools were generally sufficient, as most networks were far smaller and less complex back then. By late 1987, Request For Comments (RFC) 1024 codified “an interim response to immediate gateway monitoring needs” called “Simple Gateway Monitoring Protocol” (SGMP). SGMP defined a platform-neutral standard for monitoring the health of the gateways that knitted together the previously isolated local-area networks to form the early Internet.

After almost another two years of development, SNMP emerged in RFC 1067. The “simple” in SNMP’s name was meant to contrast with rival standards of that time, including the Common Management Information Protocol (CMIP). (CMIP was particularly popular with telecommunications companies and still has specialized uses). While SNMP has too many obscurities and blemishes to be considered truly “simple,” it is much less complex than CMIP and other rivals.

By the mid-’90s, Java and HTTP appeared to be the solutions for nearly every problem, and many vendors in the networking industry lined up to drink the Kool-aid. Their product teams abandoned SNMP for what seemed like “higher-level” solutions. But the Web and Java approaches never took over the marketplace the way fans had expected. Today they remain “specialty items,” while virtually all networking devices, including the least expensive hubs and network printers, support SNMP. If you want to manage anything or everything on your network and want to be able to choose from the broadest array of tools, expect to deal with SNMP.

SNMP Terms and Concepts

The SNMP world is filled with abbreviations, most of which you’re unlikely to have ever heard before. Here are a few of the most important:

ASN.1: An SNMP message is constructed with the Abstract Syntax Notation, version 1. ASN.1 defines integers, OIDs, octet strings, and null as its simple types.

BER: The Basic Encoding Rules represent ASN.1 data as octet strings.

MIB: A Management Information Base for a piece of equipment collects definitions of properties of the managed objects of the device. The device itself maintains the data store of properties, which might be accessible through SNMP or other means. An example of one property definition is:

SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
“The time (in hundredths of a second) since the
network management portion of the system was
last re-initialized.”

OID: An object identifier is a name that uniquely identifies a device or characteristic of a device (or more general object — outside SNMP, there are OIDs for people, documents, and so on). OIDs are written as sequences of period-separated integers, such as “”

PDU: A Protocol Data Unit is SNMP’s “datagram” — the smallest meaningful unit of network transmission. Typical SNMP PDUs include a request number, an error status, an error OID, and a list of OID-value pairs. Thus, a sysDescr response PDU most often holds a sequence index, two nulls (for the error values), the sysDescr OID, and an octet string that encodes the sysDescr value.

SMI: The Structure of Management Information is a standard that describes how SNMP accesses information. It defines MIBs and use of ASN.1. One part of the SMI says that each data item has a name, syntax, and encoding. The name is an OID. The syntax gives datatype: “integer,” “string of octets,” and so on. The encoding tells how to serialize data for platform-neutral network transmission.

SNMP Basics

SNMP is a simple client/server protocol for communicating with network devices. Much like SMTP enables mail delivery, it also enables network managers to keep track of their networks. There are some things which make SNMP a bit unusual compared to more traditional protocols.

First, SNMP systems typically involve far more servers than clients. From the perspective of network programming, individual network devices (routers, switches, printers, hubs, etc.) are the servers in an SNMP system. The client is often a single computer that polls the devices and records the data they return.

This topology reverses the more typical client/server architecture of one server and many clients. SNMP’s rather idiosyncratic vocabulary reflects its unusual design. Any device that speaks SNMP is referred to as a managed device. You can ask any managed device who (or what) it is with a request transcribed in English as GetRequest SysDescr. The answer that comes back may look like hostname:jupiter:specialOS V4.1 (Rev. 52) System #4. You can ask the device several other questions in order to collect a more complete profile of its status and history.

For any particular device, there are often other ways to retrieve the same information; if it is a Linux host, you might log in and run any of the commands that normally diagnose a machine’s state (top, vmstat, netstat, ps, etc.). If it is a router from a vendor like Cisco or Juniper, you can also log in and check the status interactively. However, SNMP allows you to gather the same data using less network bandwidth and memory. SNMP-based management systems often watch thousands of devices simultaneously with ease.

SNMP provides a uniform approach to device management. You use the same requests, and expect similar responses, no matter what operating system the device you’re monitoring may run. It doesn’t really matter whether the system it’s running is Unix, OS/400, Windows, Cisco’s IOS, or another specialized embedded operating system. If it speaks SNMP (and it probably does), you can get data from it in a consistent fashion.


It takes only a few minutes for you to start polling SNMP devices on your network. The easiest way to get started is to use NET-SNMP, a C library and collection of command-line utilities.

NET-SNMP is available in RPM and source form from http://net-snmp.sourceforge.net/. Debian users will find a .debs available from Debian mirrors. Installing from source is as easy as downloading, uncompressing, and:

cd ucd-snmp-4.2.1
make install

Gathering Data…

To understand SNMP concepts, it helps to have “live” applications and data with which you can experiment. Before you continue reading, follow the instructions in the NET-SNMP sidebar to install NET-SNMP. This will allow you to use the commands discussed below.

Like any client/server application, once you’ve installed the client, you need to locate a working server to test it against. Your best bet is probably to poke around your local network, interrogating hardware devices such as network printers, routers, hubs, terminal servers, and so on. Many of those are likely to build in working SNMP agents (servers). Two years ago, it was fairly easy to find SNMP agents on the Internet (often ISP routers). Firewalling has improved since then, so you’re probably best off experimenting with something closer to home.

Suppose target is a router or other SNMP-enabled device. From the command line, if you run:

snmpget target public sysDescr.0

you should see a brief description of the system that looks something like the following:

system.sysDescr.0 = Cisco Internetwork Operating System Software 

IOS ™ 7200 Software (C7200-IS-M), Version 12.1(5)T5, RELEASE SOFTWARE (fc1)

TAC Support: http://www.cisco.com/cgi-bin/ibld/view.pl?i=support

Copyright (c) 1986-2001 by Cisco Systems, Inc.

Compiled Tue

The public in that command is sort of a password for the SNMP agent, which is called the “community string.” It’s very common for managed devices to have “public” as their default community string. It’s not necessarily a security problem for a device to be “public” for inquiries such as this.

sysDescr.0 is an example of an object identifier (OID). More precisely, it’s the textual or “display” form of the OID, which corresponds to the numeric OID This might remind you a bit of the domain-name system (DNS), in which www.linux-mag.com is the human-readable form for an address such as

DNS, of course, translates hostnames to IP addresses (and vice-versa). SNMP uses a “management information base” (MIB), which is a text file that provides the schema of information known to SNMP, including OID translations. Many MIBs are public and in wide use. Some are proprietary and restricted to equipment from a particular vendor. RFC 1213 describes sysDescr and many other common OIDs, including sysUpTime (how recently the device was last restarted) and sysLocation (its physical location). With NET-SNMP installed, you can interrogate the MIBs yourself with such commands as:

snmptranslate -Td -OS system.sysDescr

Doing so will result in output such as that contained in Figure One. The important information in there (for now) is the DESCRIPTION. By using snmptranslate, you can easily learn (or remind yourself of) the characteristics of various SNMP OIDs.

Figure One: Output of snmp translate

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) 1 }

Programming with SNMP

While the NET-SNMP distribution comes with a C library which you can use to build your own SNMP-based applications, it’s often much easier to start out using a scripting language like Perl, Python, or Tcl instead. They all have SNMP libraries available.

For example, using Perl and the SNMP_util module form CPAN, you can easily write a simple application like the one illustrated in Listing One.

The code in Listing One prints out the name of each managed network interface on $HOST, such as 1o0, Ethernet, Serial1, and so on.

Listing One: A Simple Perl Application

# Usage: “net_if.pl <hostname>”.

use SNMP_util;

$HOST = shift;

# This is the OID for ifDescr, or, more properly,
# iso.org.dod.internet.mgmg.mib-2.interfaces.
# ifTable.ifEntry.ifDescr.

$OID = “″;

@values = &snmpwalk($HOST, $OID);

if (@values) {
print “Network interfaces for $HOST: :@values:\n”;
} else {
print “$HOST did not respond.\n”;

Don’t bother trying to write this in C, unless your situation is quite unusual. The scripting languages solve SNMP problems with way fewer lines of code than C; they also provide equal performance and portability.

Advantages and Disadvantages

While SNMP is relatively flexible and easy to use, it has some drawbacks. Its current security model is relatively weak. It’s easy to mismanage SNMP and create a “fire storm” of network traffic that serves no useful purpose. Using “modern” object-oriented or XML-based data is a hard job with SNMP. Also, the pool of managers and programmers who really understand how SNMP works is rather small.

Still, notwithstanding its problems, SNMP is the best we’ve got. It is universal. The networking industry has far more experience with SNMP and its security deficiencies than with those in the Web or Java worlds. The release (earlier this year) of the latest RFCs on SNMP version 3 (SNMPv3) addresses the worst security problems. SNMP is much lighter on your network than the alternatives. New devices continue to come on the market with SNMP support.

Into the 21st Century…

SNMP was invented by serious people to solve a serious problem: how does an organization manage hundreds or thousands (or even millions) of active network devices and the networks connecting them?

The typical SNMP-based application in production isn’t as simple as the snmpget program. It is more likely to be a “management console” — a kind of graphical “dashboard” which makes it easy to visualize, navigate, and identify network elements. Products from Hewlett-Packard (generally branded as “OpenView”), IBM (Tivoli), BMC Software, Computer Associates, and others fall into this category of applications. And yes, they’re all expensive.

Although SNMP is over ten years old, there’s still plenty new to learn about it. SNMPv3 extends the earlier versions of SNMP to solve longstanding issues with security and management. It also introduces a module architecture designed to make SNMPv3 extensible enough to obviate any need for a SNMPv4.

The growth of Linux has played a role in SNMP’s continued growth. All major Linux distributions include basic SNMP software, although few install it by default. More than that, the Linux emphasis on standards-based solutions contrasts with the directions taken by Microsoft and other vendors.

Probably the most important news in the SNMP world is simply the change in attitude. Throughout the ’90s, practitioners widely accepted that:

  • SNMP is difficult to learn and use.
  • SNMP applications must be coded in low-level programming languages (like C).
  • SNMP management tools are very expensive.
  • Vendors frequently hide their MIBs or break the rules of SNMP.
  • Devices will be used the way vendors expect and only by experts.

All of these are changing now. A new generation of developers and administrators are accustomed to interfaces they find convenient, not necessarily the ones vendors supply. Newsgroups and Web sites distribute knowledge about SNMP once available only to the insiders. Engineers familiar with open source virtues are demanding standards-based solutions. Organizations are realizing that some of their best management applications are built with open source software.

It’s increasingly unnecessary to memorize the numeric OIDs for the different kinds of network traffic measurements; well-designed applications build those semantics in and present human operators with human-readable displays. In addition, well designed libraries for higher-level languages are making it increasingly easier to program for SNMP.

Network Management is a serious job best performed with standards-based solutions. SNMP makes this possible. Open source software makes it easy.


The NET-SNMP Project Home Page (source code is available from this site): http://net-snmp.sourceforge.net

MRTG: The Multi Router Traffic Grapher: http://www.mrtg.org

Big Brother System and Network Monitor: http://maclawran.ca/bb-dnld

The Distributed Management Task Force, Inc. (DMTF): http://www.dmtf.org

Web-Based Enterprise Management (WBEM) Initiative: http://www.dmtf.org/standards/standard_wbem.php

SNMP4tPC — SNMP RFC Information and Links: http://www.wtcs.org/snmp4tpc/snmp_rfc.htm

Essential SNMP: http://www.oreilly.com/catalog/esnmp

Index of the CPAN (Perl) SNMP Library Directory: http://www.cpan.org/modules/by-module/SNMP

RFC 1213 — MIBs: http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1213.html

Cameron Laird is Vice President of Phaseit, Inc. He can be reached at cameron@phaseit.net.

Comments are closed.