Traps are coming in, and mibs are read correctly, but the traps do not seem to trigger alerts

[dbusse]

Hello,

I am in need of some help with SNMP traps. I’ve been working on this for a couple days now.

Setup:
LibreNMS is running in a docker stack
SNMPD is running and working as expected
The device sending the traps is an HP 5406zl2 L3 switch

Issue:
I can see incoming trap messages in the event log (refer to screenshot). It seems to be interpreting these just fine. However no alerts are ever triggered by SNMP Traps.
Currently I am trying to get alerts for when uplink/trunk ports go down/up.
I have managed to get port up/down messages from polling with SNMPv3, but I want certain things like the port up/down messages to use traps instead, so that the reporting of the port going down is a instantaneous as possible. I read on documentation and forums that alerts.php only runs every minute, so I made sure to wait a few minutes to see if the alert comes through, but it never does.

[dbusse]

Update:

I’ve done some digging and I think I have found the root of the issue, but I am unsure of how to solve it.

If you refer to the image above, you’ll see two messages. One trap denoting the port is down, and one labeling it as disabled. For some reason, the port is being updated as “disabled” rather than “down” and this is causing the UP/Down alert not to be triggered.

The way I have been testing the alert, is to unplug a testing switch, which is plugged into a different switch (core), on port C1, labeled “Uplink-deven-desk”, which causes the messages seen in the screenshot above.

[laf]

I think the first you will need to do is look at the actual raw trap that comes in on port 162 udp to see if your device is sending a disabled trap rather than down trap, if it is then you’ll need to take this up with the vendor.

[dbusse]

It seems to send both traps.

I have found a work around, but I’m not sure if this is the proper way of doing it, but ill attach a screen shot of what I changed in the alert rule. Essentially, I had it look for ports.ifoperstatus rather than use the macros.port_down.

it seems to me, that it is changing the status of the port to down, but also disable. Which seems to cause the macros.port_down to see the port as “disabled” rather than “down”

[laf]

So from the code, it’s being marked as disabled because ifAdminStatus is changing state as well, is your device sending ifAdminStatus down trap? If so, that’s why you are seeing the disabled message.

However the port_down macro won’t work if the ifAdminStatus is down as well because that means you chose to shut the port down - bad snmptrap from your device I think.

[dbusse]

Thanks for the help. Im going to reach out to HP and ask if there is something they can do to help me.

For now the work around above seems to work just fine.

Im currently having an issue with the API/Oxidized. But ill open a new topic of that. Thanks so much.

[dagbdagb]

For what it’s worth:
I have seen the same behavior with Fortinet devices. admin status and oper status moving in lockstep, making the data useless for alerting purposes.