Logging messages with SNMP

"Q: Why is SNMP like golf? A: Usually the fewer polls you take the better off you are, but you are sometimes lost in the woods and it helps to have a good set of tools in the bag and it helps to have good instructions and you need a few beers after a bad round."
- Anon.

For the past few weeks we have been enjoying the intricacies of syslog, a protocol used to send status messages from one device to another over an IP-based network. We hadn't mentioned yet that in many syslog clients you can set the address for where to send syslog messages.

So if you want more than one syslog collector or relay to receive the messages you need to use a broadcast address, that is, x.x.x.255 (see our first piece on syslog for terminology).

But before you make great plans based on syslog broadcasting, be sure to check that the client can broadcast correctly and that the syslog collector can actually hear broadcast messages.

Anyway, as we said in that first syslog piece: There are four main methods for logging system or process status messages - syslog messages, SNMP traps, logging to a local text file and console logging. We've covered syslog and we feel that there is little to be said on text file and console logging so . . . you guessed it, we're going to look at SNMP! Oh, the joy.

The first version of SNMP, which was based on a previous management protocol called Simple Gateway Monitoring Protocol, was defined in the Internet Engineering Task Force (IETF) RFC 1067, published in 1988. After several updates, and enhancements, the standard appeared in its final form in RFC 1157 "A Simple Network Management Protocol" dated 1990.

The basic communication architecture of SNMP is straightforward; there are three types of requests and one unsolicited information transmission.

To get information from an SNMP device, a "manager" (SNMP terminology for a client) will send a "GetRequest" or "Get"NextRequest" to an "agent" (the SNMP term for a server) and the requested information or an error message will be sent back in a "Response." If a manager wants to modify information on an agent, a "SetRequest" will be sent with a corresponding response to confirm or report an error.

The unsolicited message form is called a "trap." This kind of message is usually sent by agents on start-up, on status change and in response to error conditions. Traps are not only unsolicited but they are also unreliable. Like syslog messages they are sent via User Datagram Protocol and whether they are received depends on whether they make it to the destination (remember, UDP is an unreliable, best-effort service) and whether the manager is listening.

The information on the agent is stored in what is called a Management Information Base (MIB). This is a hierarchical data structure (not, as it is often mistakenly called, a database) that describes all the "objects" that a device can report the status of and, in some cases, set the value of.

The structure of the MIB is laid out in an SNMP-related standard, RFC 1155 "Structure and Identification of Management Information for TCP/IP-based Internets," which defines how MIB information is organized and what data types are allowed and how resources within the MIB are represented and named.

The formal model for defining objects and tables of objects in the MIB is the Abstract Syntax Notation One (ASN.1) OBJECT TYPE macro.

That's the overall architecture. Following the standardization of SNMP Version 1, there were all sorts of proposals for improving the protocol. In 1992, development of SNMP Version 2 began, and in 1993, it became a proposed standard.

Of course, more was required of SNMP than Version 2 offered, so work began on Version 3 and the IETF Steering Group approved Version 3 as a draft standard in 1998 and as a full standard on April 8, 2002. Versions 1 and 2 were moved to historic status. Of course, it will take a while for Version 3 to become ubiquitous, so you'll see lots of both previous versions out there.

Next week we'll delve into SNMP message structure and MIBs and the week after, a tool that handles SNMP traps and syslog messages with élan and aplomb.

RELATED LINKS