Not getting SNMP data in OpenNMS

We have developed an IoT type device that includes an SNMPv3 agent. We are able to query the device and get all of the data using snmpwalk and also with PRTG. One of the requirements is that the data can be collected using OpenNMS but we can’t get that to work.

At the moment we are struggling to understand whether this is an issue with the SNMP agent in the device or whether we have something misconfigured in OpenNMS.

We have OpenNMS Horizon v26.1.0 installed on a Debian box. I have imported the MIB file that goes with the device and a file has been created as <opennms_install_dir>/etc/datacollection/Device-MIB.xml.

In the OpenNMS UI I have a node which shows HTTPS, ICMP and SNMP in the availability graphs which is correct - these are the three enabled protocols. If I look at the SNMP Interfaces under “Node Interfaces” it states “There are no SNMP interfaces for this node”.

How do I link this node to the imported MIB file?

-Andy.

When looking at your node in OpenNMS, do you see a “SNMP Attributes” section that has device info and a sysObjectID? This will indicate if OpenNMS is able to detect that SNMP is properly running on the device. Make sure that sysObjectID matches the mask ony our datacollection config so that OpenNMS knows which OIDs to poll on the device.

The only information I appear to be able to find shows:

All of the OIDs that relate to my device start 1.3.6.1.4.1.19011.1.3.5.1. Is there a standard OID that my device needs to support that is queried by OpenNMS that returns that value or is it something I define in OpenNMS when creating the node?

-Andy.

To collect SNMP data, the System Object is important as @mmahacek explained. It is detected during the provisioning of the node and uses the SNMP community which you have provided in the UI “Admin -> Configure SNMP Community Names by IP Address”.

The service SNMP is probably detected as well, which is what you have shared in your screenshot. The SNMP service is there just to test if the SNMP agent is still up and responding (Service Monitoring with Pollerd). For the reason, SNMP is UDP we test the status of the devices SNMP agent with a test by trying to fetch the System Object ID. It is a crucial element to identify the class of a device and should be implemented by any device which follows SNMP compliance. So this might here be confusing and has nothing to do with “data collection”.

From your description, it seems you want to collect metrics which is a separate domain of concern in OpenNMS done by “Collectd”. One key component is the “System Object OID” detected of the Node during provisioning. You can verify it on the Node Detail Page in the box “SNMP Attributes” like here:

The System Object ID allows classifying the device for vendor/type/capabilities. To tell Collectd which metrics should be collected for which device, the systemDef entries are used like these here for Net-SNMP where they have registered 8072 for their Net-SNMP specific things:

<systemDef name="Net-SNMP">
  <sysoidMask>.1.3.6.1.4.1.8072.3.</sysoidMask>
  <collect>
    <includeGroup>mib2-host-resources-system</includeGroup>
    <includeGroup>mib2-host-resources-memory</includeGroup>
    <includeGroup>mib2-host-resources-storage</includeGroup>
    . 
    .
  </collect>
</systemDef>

That means for every device which fits in the class of the System Object ID mask, OpenNMS tries to collect the metrics defined in the includeGroup sections.

I hope this clarifies it a little bit and points you in the right direction.

Hmm, when I look at the same page as you have captured I don’t have an “SNMP Attributes” section!

I have been through “Admin -> Configure SNMP Community Names by IP Address” and using the IP address for the device it brings up all the correct SNMPv3 information for accessing the device so as far as I can tell that looks right.

In the <opennms_install_dir>/etc/datacollection/Device-MIB.xml file that was generated by importing the MIB file I have added:

   <systemDef name = "Net-SNMP">
      <sysoidMask>.1.3.6.1.4.1.19011.1.3.5.1.</sysoidMask>
      <collect>
              <includeGroup>pzIdent</includeGroup>
      </collect>
   </systemDef>

This corresponds to the following group:

Hmm, when I look at the same page as you have captured I don’t have an “SNMP Attributes” section!

I have been through “Admin -> Configure SNMP Community Names by IP Address” and using the IP address for the device it brings up all the correct SNMPv3 information for accessing the device so as far as I can tell that looks right.

In the <opennms_install_dir>/etc/datacollection/Device-MIB.xml file that was generated by importing the MIB file I have added:

   <systemDef name = "Net-SNMP">
      <sysoidMask>.1.3.6.1.4.1.19011.1.3.5.1.</sysoidMask>
      <collect>
              <includeGroup>pzIdent</includeGroup>
      </collect>
   </systemDef>

This corresponds to the following group:

   <group name="pzIdent" ifType="ignore">
      <mibObj oid=".1.3.6.1.4.1.19011.1.3.5.1.1.1" instance="0" alias="pzIdentManufacturer" type="octetstring"/>
      <mibObj oid=".1.3.6.1.4.1.19011.1.3.5.1.1.2" instance="0" alias="pzIdentProductName" type="octetstring"/>
      <mibObj oid=".1.3.6.1.4.1.19011.1.3.5.1.1.3" instance="0" alias="pzIdentFirmwaVersio" type="octetstring"/>
      <mibObj oid=".1.3.6.1.4.1.19011.1.3.5.1.1.4" instance="0" alias="pzIdentSerialNumber" type="octetstring"/>
   </group>

If I run the following command ./snmp-request -v 3 -a MD5 -A password -u snmpuser -x DES -X test1234 -Ow 192.168.10.137 .1.3.6.1.4.1.19011 then I get all of the correct output that I expect from the device.

If it makes any difference to the situation, the device is based on FreeRTOS and the SNMPv3 agent is a small footprint embedded one that we have licensed from a third-party.

-Andy.

Yes, this is the first point to start investigating, why you don’t have the SNMP Attributes? Without them our “Collectd” won’t start anything to collect. Do you provision the node in a requisition which I would recommend? The information to fetch the “SNMP Attributes” is triggered a) when you synchronize the requisition or b) you hit “Rescan” on the “Node Detail Page”. The provisiond.log file can help troubleshooting why this information can’t be fetched.

Secondly, you probably should rename your System Definition to something different than Net-SNMP, e.g. Jacarta or something related to your device types.

<systemDef name = "Net-SNMP">
  <sysoidMask>.1.3.6.1.4.1.19011.1.3.5.1.</sysoidMask>
  <collect>

I suspect that somewhere along the line I may have been blindly hacking my way through some of the configuration files. Is there a simple way to uninstall OpenNMS and delete the database so that I can re-install everything cleanly and try again?

-Andy.

There are three things:

  1. The configuration, in ${OPENNMS_HOME}/share/etc-pristine is a copy of configuration files as they come when you install it
  2. Time series data is in ${OPENNMS_HOME}/share/rrd/response and ${OPENNMS_HOME}/share/rrd/snmp
  3. Database with all data including the schema can be dropped and recreated with install -dis command.

I have tried running all those steps but when I restart OpenNMS and login as the admin user I can still see references to the previous nodes. Having recreated the database I would have assumed all of those should have gone.

-Andy.

I have managed to find some more time to look at this, starting with completely uninstalling OpenNMS and PostgeSQL and re-installing them. OpenNMS seems to have updated itself again so I am now using v26.1.1.

So far, the steps I have been through are…

Using Admin -> SNMP MIB Compiler imported SNMP-FRAMEWORK-MIB.txt (downloaded from http://net-snmp.sourceforge.net/docs/mibs/SNMP-FRAMEWORK-MIB.txt) as my .MIB file has a dependency on it.

Still in the SNMP MIB Compiler I imported my .MIB file and when it was in the “Compiled” list I right clicked on it and chose the “Generate Data Collection” option to create the .xml file in ${OPENNMS_HOME}/etc/datacollection/myfile.xml.

Edited ${OPENNMS_HOME}/etc/datacollection-config.xml to add an <include-collection ... /> line.

Using Admin -> Configure SNMP Community Names by IP Address put the device IP address into the “IP Address” field and clicked the “Look Up” button. I then filled in the “General Parameters” information setting the version to v3 and putting all the credentials into the right boxes.

Using Admin -> Manually Add an Interface I entered the IP address to add the device. When I look under the nodes I still see:

I am still missing the “SNMP Attributes” section you showed in the image above. Still not sure what I am doing wrong!

-Andy.

You probably aren’t doing anything wrong. I have that same issue with a few devices that do not respond with the necessary SNMP fields to generate that section. Without that section being returned, I haven’t been able to get SNMP data collected for my device.

As I am developing the firmware for the device and am responsible for what SNMP fields are returned and what is contained within them that is the information that I am looking for.

-Andy.

Check out this article. Understanding SNMP. Specifically, check if your device is publishing OIDs .1.3.6.1.2.1.1.[1-6].0

1 Like

If I run the command ./snmp-request -v 3 -a MD5 -A password -u snmpuser -x DES -X test1234 -Ow 192.168.10.137 .1.3.6.1.2.1.1 then I get the following output (some names changed to protect the innocent):

Using SNMP4J from: /usr/share/opennms/lib/snmp4j-2.5.5.jar
Using log4j-over-slf4j from: /usr/share/opennms/lib/log4j-over-slf4j-1.7.26.jar
Using SLF4J API from: /usr/share/opennms/lib/slf4j-api-1.7.26.jar
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
1.3.6.1.2.1.1.1.0 = XXXXXXX
1.3.6.1.2.1.1.2.0 = 1.3.6.1.4.1.19011.1.3.5.1
1.3.6.1.2.1.1.3.0 = 2 days, 9:12:24.87
1.3.6.1.2.1.1.4.0 = XXXXXXX
1.3.6.1.2.1.1.5.0 = 
1.3.6.1.2.1.1.6.0 = UK
1.3.6.1.2.1.1.7.0 = 70
1.3.6.1.2.1.1.8.0 = 0:00:00.00
1.3.6.1.2.1.1.9.1.2.1 = 1.3.6.1.2.1.2
1.3.6.1.2.1.1.9.1.3.1 = The MIB module to describe generic objects for network interface sub-layers.
1.3.6.1.2.1.1.9.1.4.1 = 0:00:00.00

Total requests sent:    11
Total objects received: 11
Total walk time:        1962 milliseconds

Are the missing values for 1.3.6.1.2.1.1.5.0 and 1.3.6.1.2.1.1.9.1.3.1 the issue?

-Andy.

I’m not 100% sure, but it is possible.

Doing some reading on the internet. It appears that we aren’t returning any of the .1.3.6.1.2.1.2 OIDs that define the network interface. I’m going to try adding those and see what happens.

-Andy.

Sorry for the delay in responding but my efforts had been redirected to dealing with other issues. I have implemented a number of additional system OIDs: 1,3,6,1,2,1,1,x,0, 1,3,6,1,2,1,1,9,1,x, 1,3,6,1,2,1,2,1,0 and 1,3,6,1,2,1,2,2,1,x.

When OpenNMS is started Wireshark shows me some communication with the SNMP interface in the device which includes the device specific OIDs in the response.

Wireshark then doesn’t ever seem to capture any more packets that are SNMP related. This makes me skeptical that OpenNMS is actually trying to capture data.

I also still don’t see the “SNMP Attributes” section as per the image that @indigo showed in one of his replies.

This is now starting to feel like there is something missing from the OpenNMS configuration but I can’t figure out what.

-Andy.