SNMP manages information via a Management Information Base (MIB), which is a tree-like structure that contains hierarchical information in ASN.1 format. Each SNMP agent has a list of information it can extract from the local system, arranged in a hierarchical SNMP MIB with very general main categories, such as network, physical, programs, and so on.

Think of the MIB tree as a well-organized filing cabinet, where individual drawers hold specific information, and files within drawers hold particular facts. Similarly, the uppermost MIB contains a list of MIBs beneath it.

interfaces.ifTable.ifEntry.ifDescr.1 = STRING: "em0"

.1.3.6.1.2.1.2.2.1.2.1 = STRING: "em0"

The most common alternate acronym for SNMP is “Security? Not My Problem!” This is unkind, but true. You should use SNMP only behind firewalls or on trusted networks. If you must use SNMP on the naked Internet, employ packet filtering to keep the public from querying your SNMP service. SNMP agents run on UDP port 161, so allow your management hosts access to that port on only your SNMP hosts.

SNMP provides basic security through communities. If you read the SNMP documentation, you’ll see all kinds of explanations of why a community is not the same as a password, but as far as a sysadmin is concerned, a community is a password.

Most SNMP agents have two communities by default: public (read-only access) and private (read-write access). OpenBSD’s snmpd daemon supports both of these communities by default. One of your first tasks will be to change these community names to something that the whole world doesn’t know. Just like passwords, community names should be hard for intruders to guess and easy for you to remember.

As you might expect, there have been various versions of SNMP. Version 1 was the first attempt. Version 2c (SNMPv2c) is the more commonly deployed update. Version 3 (SNMPv3) uses encryption to protect data on the wire, and it includes strong authentication. In practice, few vendors actually use it because it’s very complicated. The snmpd daemon has partial support for SNMPv3. Here, we’ll focus on the completely supported SNMPv2c.

Configure snmpd in /etc/snmpd.conf. The configuration format is a series of text statements. Defining new community strings overrides the defaults of public and private.

We start by defining new read-only and read-write community strings, as follows:

read-only community hansteen
read-write community henning

In general, most snmpd configuration statements look like these two. The snmpd.conf(5) man page lists all valid snmpd.conf configuration statements.

Every SNMP system is expected to list a contact, a description, and a location, as in this example:

system contact "[email protected]"
system description "Web server"
system location "Rack Row 9, Cabinet 6, Under the Meal Replacement Bars"

Many network management systems will automatically pull in this information to populate the database. Here, I’ve defined these values for my system. Make similar entries for your system.

The default snmpd.conf listens to only the localhost IP address, 127.0.0.1, so outside hosts cannot contact the SNMP daemon. If you want to listen on all available addresses, comment out the lines, like the following, that specify an address.

listen_addr="127.0.0.1"
listen on $listen_addr

Alternatively, you can give an interface IP address to have snmpd listen to a specific external IP address for those machines with many addresses.

listen_addr="192.0.2.5"

With this configuration, snmpd can provide information about your system. Enable it in /etc/rc.conf.local.

snmpd_flags=""

This will start snmpd at boot, or you can run /etc/rc.d/snmpd.

SNMP can be an annoying protocol to debug. For one, because it’s UDP, there’s no easy way to test connectivity to the agent. Also, it runs fairly silently, in that it doesn’t log queries.

To verify that queries from your network management system are reaching your server, try running snmpd in verbose mode and with debugging.

# snmpd -vd
startup
snmpe_bind: binding to address 0.0.0.0:161

When an SNMP query reaches your server, you should see the server parse the requests. By the same token, snmpd is very good about telling you why it can’t provide an answer.

snmpe_parse: 192.0.2.197: wrong read community

Errors, like the following, that arise from requests for a nonexistent MIB are a little more difficult to understand.

snmpe_parse: 192.0.2.197: SNMPv1 'henning' context 1 request 1141724535
snmpe_parse: 192.0.2.197: oid iso.org.dod.internet.private.enterprises.2041
snmpe_parse: 192.0.2.197: SNMPv1 'henning' context 0 request 1141724536
snmpe_parse: 192.0.2.197: oid iso.org.dod.internet.private.enterprises.2041
snmpe_parse: 192.0.2.197: invalid varbind element, error index 1

Here, the MIB request is trying to find the object identifier (OID) iso.org.dod.internet.private.enterprises.2041, but OpenBSD’s snmpd does not support that. (It does support 202 1, part of the Net-SNMP MIB.) The SNMP client is requesting an invalid MIB.

This example shows a successful request and the MIB that snmpd sends in response:

snmpe_parse: 192.0.2.197: SNMPv1 'henning' context 1 request 1531862688
snmpe_parse: 192.0.2.197: oid iso.org.dod.internet.private.enterprises.ucDavis

By reading the output carefully, you should be able to see why snmpd is not answering requests as expected.

The most important feature of SNMP is that it lets you read statistics from the operating system and/or software. In addition to the usual features supported by SNMP, such as resource utilization and processes, snmpd lets you grab OpenBSD-specific system information. You can get information about the packet filter, sensor data, interface memory, and Command Address Redundancy Protocol (CARP). All of this appears under the .1.3.6.1.4.1.30155 MIB, OpenBSD’s private (enterprise) MIB tree.