Some notes on finding and reading information over SNMP

April 1, 2022

Suppose, not hypothetically, that you have some servers of interest which provide interesting information through their BMC's web server that they don't expose through IPMI in any non-proprietary way. But their BMC does support SNMP, the Simple Network Management Protocol, and perhaps they expose the information in SNMP. You would like to peer through the information the BMC exposes over SNMP, which requires actually understanding a bit of SNMP. Since I went through this today, here are some notes (for a future me if no one else).

SNMP is of course not simple. The information you get over SNMP is organized into a tree of OIDs, which are dot-separated decimal identifiers that look like 1.3.6.1.4.1 (except they get much, much longer). What a given area of the OID tree actually means is described by MIBs, and generally you want to have the relevant MIBs in order to understand what you're seeing. Some MIBs are standard and probably come with your SNMP tools, but a lot of interesting information exposed through SNMP is vendor specific and so you need to get the vendor MIBs. In theory the vendor websites should be the best place to get these. In practice, vendors make this a giant pain, so everyone goes to various sites that collect the MIBs, index them, archive them when vendors remove them from their website, and let you download them in an easy and uniform way.

(For example, 1, 2, 3, 4, 5, 6, 7. The way you find these sites is to do a web search on some interesting OID.)

A very important OID tree that you will see a lot of starts at "1.3.6.1.4.1.". This is the normal SNMP 'private enterprise' top OID, and vendors are assigned unique numbers under this. If you're looking for vendor specific SNMP information, it's very often found somewhere under here under the numeric identifier for the vendor, such as "1.3.6.1.4.1.21317". A hypothetically complete list of vendor numbers is maintained by IANA in enterprise-numbers. Searching this list will show you, for example, that 21317 is ATEN International. When you're specifically dealing with BMCs, the BMC is often made by someone other than the main system maker. This can also be used to determine who makes your BMC if you're not sure. If you use SNMP tools to scan under 1.3.6.1.4.1 and entries appear under .21317., you can be pretty sure you have an ATEN BMC regardless of whose name appears on the server case.

Sometimes you may wind up reading MIBs to see what's in them, and in these circumstances you may want to have a simple way to map between declarations in the MIB and OIDs, so you can go poke your device to see if it has useful OIDs. In the MIB format I've seen so far, OIDs are declared relative to other things; for example:

aten MODULE-IDENTITY
  [....]
  ::= { enterprises 21317 }

ipmi      OBJECT IDENTIFIER ::= { aten 1 }
[...]
powerinfo OBJECT IDENTIFIER ::= { ipmi 14 }

The 'enterprises' OID is imported earlier in the file, so we can see that the root of the OID tree here is 1.3.6.1.4.1.21317, the ATEN vendor OID. Within that, .1 is information from the IPMI, and .1.14 is power information. If we query our BMC for 1.3.6.1.4.1.21317.1.14 and get nothing, we can sadly conclude that while the ATEN MIB holds out the possibility of this information being available through SNMP, it does not actually appear in our BMC's SNMP information, for whatever reason.

On top of this sadness, even having a MIB doesn't tell us how to interpret the values that we read out via SNMP. For instance, the Supermicro ATEN IPMI MIB will tell us that there is a PSU "Input Voltage", but the only thing it tells us about how the voltage is reported is:

inputVoltage OBJECT-TYPE
  SYNTAX   OCTET STRING (SIZE(16))

What those 16 bytes mean is opaque from this information alone. Similarly, there are PSU temperatures in that MIB, but all they say about what units is:

temperature1 OBJECT-TYPE
  SYNTAX   Integer32 (1..256)

This could be degrees Celsius or tenths of degrees Celsius or something else entirely. You can read fun stories of people trying to reverse engineer SNMP conversion factors for motherboard voltages, for example.

(While MIBs can have textual descriptions of what each OID may mean, don't count on them to be useful. A significant portion of the sensor OID descriptions in this ATEN MIB I'm looking at appear to have been copied from OID descriptions for network interfaces. That no one noticed or fixed it tells you some things about how MIBs are used and how much I expect vendors care about them.)

PS: In this specific case, we have another machine that does appear to expose this information, so I can say that the input voltage appears to be the voltage in ASCII and the temperature seems to be degrees C. Exposing readings as ASCII seems to be common in SNMP; we have other devices that do it.

Written on 01 April 2022.
« The awkward timing of Fedora and Go releases
Sorting out IPMI and BMC terminology and technology »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Apr 1 22:28:45 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.