2007-08-20 by sourpoi in misc, tagged: snmp net-snmp oid pen

The goal is to associate a custom script with an object identifier (OID) that SNMP managers can use to query a Net-SNMP agent.

To start, do the right thing and register for an IANA Private Enterprise Number (PEN) at http://pen.iana.org/pen/PenApplication.page. See the list of registered PENs at http://www.iana.org/assignments/enterprise-numbers. PEN OIDs begin with 1.3.6.1.4.1, so a PEN of 32473 [1] will result in a prefix of 1.3.6.1.4.1.32473 for private objects.

See EXTENDING AGENT FUNCTIONALITY in man snmpd.conf.

While writing custom scripts, keep in mind that:

  • per RFC 2578, OID names (the string IDs associated with the OID number) should be kept under 32 ASCII characters, and
  • custom programs should finish in less than 3 seconds and have an exit status of 0.

Add the custom script to snmpd.conf:

exec demoecho /bin/echo I enjoy pizza.

Tell snmpd to re-read snmpd.conf:

kill -HUP `pidof snmpd`

At this point, I rest on faith that the exec configuration will create an extNames.1 OID (see related comments in a default snmpd.conf):

snmpwalk -Os -c $COMMUNITY_STRING -v 2c 127.0.0.1 extNames

extNames.1 = STRING: demoecho

Without specifying the OID in the exec line, it will be set automatically. Find out what it is using the -On option:

snmpwalk -On -c $COMMUNITY_STRING -v 2c 127.0.0.1 extNames

On my system, this returned .1.3.6.1.4.1.2021.8.1.2.1 = STRING: demoecho.

Compare the output from the following to see how the name (string) and numeric representations of an OID match up:

snmpwalk -Os -c <community_string> -v 2c 127.0.0.1 .1.3.6.1.4.1.2021.8

snmpwalk -On -c <community_string> -v 2c 127.0.0.1 .1.3.6.1.4.1.2021.8

Following the pattern above, configure the script's OID with the 32473 PEN:

exec .1.3.6.1.4.1.32473.8.1 demoecho /bin/echo I enjoy pizza.

Repeat the snmpwalk commands above to see that the output for the "general" .1.3.6.1.4.1.32473.8 section reserves 32473.8.1.* for demoecho. By adding another exec with a .2 extension and HUP-ing the process:

exec .1.3.6.1.4.1.32473.8.2 demoecho2 /bin/echo I like mushrooms and olives.

snmpwalk will show that the two exec statements are nicely organized in 32473.8.1.* and 32473.8.2.* subgroups.

In the process of changing assigned OIDs, removing them, adding them again, and SIGHUPing snmpd some changes did not take effect after reassigning an exec to a previously-used OID. Errors appeared in /var/log/messages (not /var/log/snmpd). It seems that if you add a new exec with a unique OID you can HUP snmpd without issue, but if you try to mix and match OIDs between HUPs it will mess up the database. If errors occur and changes do not show up, a HUP may not be enough and you'll probably need to restart snmpd.


To be complete on Red Hat-based systems [2] , create custom MIBs and configure snmpd to run with -m +new_mib in /etc/snmp/snmpd.options (since that's what /etc/init.d/snmpd checks). man snmpcmd gives the default MIBs loaded by snmpd in the ENVIRONMENT VARIABLES section and the MIBs are located in /usr/share/snmp/mibs/.

[1]32473 is the sample PEN in RFC 5612.
[2]HP-UX's Internet Express package of Net-SNMP is similar to Red Hat's. See man snmp, -e extendFile, and /opt/iexpress/net-snmp/etc/EXAMPLE.conf for differences.

Comments