0

I am setting up OpenNMS on an Ubuntu server to listen to a stream of SNMP traps from an external EMS and ran into an issue. I can successfully receive traps I am sending from the server where OpenNMS is installed, however OpenNMS doesn’t see any traps coming from outside.

At first it seemed like a firewall issue, but I can see the incoming traps via Wireshark on OpenNMS server, so the packets are not dropped. I’ve enabled debug-level logging for trapd and the log doesn’t show any activity when I see a new trap from EMS appear in Wireshark. The traps I am sending manually are properly logged in trapd log and shown in OpenNMS dashboards.

Either I am missing some piece of configuration, or there is a deeper firewall/OS issue at work here. Just case, here is the trapd-configuration.xml and snmp-config.xml I am currently using.

<trapd-configuration xmlns="http://xmlns.opennms.org/xsd/config/trapd" snmp-trap-address="*" snmp-trap-port="162" new-suspect-on-trap="true" include-raw-message="false" threads="0" queue-size="10000" batch-size="1000" batch-interval="500" java.net.preferIPv4Stack="true">
    <snmpv3-user security-name="ems-username" security-level="1" engine-id="800000a10352540001e90a"/>
</trapd-configuration>

Some comments on trapd config - the EMS uses SNMPv3 noAuth mode, hence security-level=1; java.net.preferIPv4Stack="true" was added as I found it as a potential solution in another thread, but presence/absence of this parameter does not seem to impact the situation.

<snmp-config xmlns="http://xmlns.opennms.org/xsd/config/snmp" security-name="ems-username" version="v3" read-community="public" timeout="1800" retry="1" port="162">
   <definition write-community="private" port="161">
      <specific>[EMS ip]</specific>
   </definition>
</snmp-config>

Would appreciate any leads on how this issue can be solved.

Oleksiy
  • 1
  • 3
  • Questions by @TarusBALOG: Okay, there are a couple of things to check. First look in /var/log/opennms/trapd.log for anything out of the ordinary. Make sure nothing else is bound to port 162 as that is the port needed by the trapd daemon to receive traps. Next, you can edit /etc/opennms/log4j2.xml and find the "trapd" section near the bottom. Set the level from "WARN" to "DEBUG". Within 60 seconds the trapd.log file should start showing DEBUG level logs. Then try to send your trap again and post any errors you find here. – Ralf Stubner Jun 11 '18 at 17:00
  • What you describe sounds similar as described [here](https://stackoverflow.com/questions/50031889/opennms-snmpv3-traps-and-informs). We solved an [issue](https://issues.opennms.org/browse/NMS-10009) with the Horizon 22.0.0 which solved a problem which sounds similar to what you experience. What version of OpenNMS Horizon do you have running? – indigo Jun 12 '18 at 18:00
  • Hi Ralf, I enabled the debug-level logging for trapd, however I don't see any events there when I can see a trap from external source via Wireshark. I do see events related to trap processing if I send an SNMP v3 trap manually from the same server. Regarding port 162, I checked via netstat and there seem to be only one process using it, which I assume to be OpenNMS. – Oleksiy Jun 12 '18 at 19:37
  • @indigo Yes, I've already seen that thread and moved the trapd in startup sequence as described there. The issue still persisted, unfortunately. – Oleksiy Jun 12 '18 at 19:39
  • Some trap messages are accepted, while others not. Then why cannot you compare every fields in Wireshark? I didn't see you did anything like that above. – Lex Li Jun 12 '18 at 21:51
  • All traps from external sources are not accepted by OpenNMS and not reflected in OpenNMS logs in any way, but are seen in Wireshark. All traps sent from localhost are accepted (even deliberately malformed ones still get reflected in logs). iptables has been disabled on the machine. To be honest, I'm not sure what to look for in wireshark, as it seems to be more of an OpenNMS configuration issue, not connectivity issue. – Oleksiy Jun 13 '18 at 18:44

0 Answers0