Minor bug found in poller/new ospf port module

Help
#1

Fyi I think I found a minor bug since the updates over the weekend.
I had just updated last week, and updated again Tuesday to get the new changes for OSPF ports (awesome BTW).
As soon as I updated I had a bunch of devices show up as “unpolled in the last 15 minutes”

all of the unpolled devices are fortinet fortiswitches of varying models.
the devices appear to be polling, all graphs -except- “poller time” are updated.
no errors in poller_wrapper.log
output of poller.php -h hostname ends with:

Error: OID not increasing: ospfIfTable >= sysDescr.0
Too few arguments to function LibreNMS\Modules\Ospf::LibreNMS\Modules{closure}(), 2 passed and exactly 3 expected {“exception”:"[object] (ArgumentCountError(code: 0): Too few arguments to function LibreNMS\Modules\Ospf::LibreNMS\Modules\{closure}(), 2 passed and exactly 3 expected at /opt/librenms/LibreNMS/Modules/Ospf.php:115)"}
In Ospf.php line 115:
Too few arguments to function LibreNMS\Modules\Ospf::LibreNMS\Modules{closure}(), 2
passed and exactly 3 expected

manually disabling the OSPF poller module on these devices makes them happy again and the error at the end of poller.php -h is gone.

#2

Hi,

We are hitting the same exact issue on Mikrotik SwOS based devices (for example RB260GS). What is weird that:

  • I can’t disable it in settings/discovery/discovery_modules (it doesn’t show there)
  • I can’t disable it with lnms config:set discovery_modules.ospf false
  • I can disable it on per device basis and then error goes away

If I don’t disable this module it basically brakes the discovery process.

Kind regards,
Michał

#3

Wait, it is breaking discovery? The ospf module does not have discovery.

#4

Can either of you give me an snmpwalk of OSPF-MIB::ospfIfTable?

#5

Hey!

I already provided output in the issue I just opened - https://github.com/librenms/librenms/issues/13532 . It looks like the output of snmpwalk is just empty there:

[email protected]:/opt/librenms# snmpwalk -v1 -c XXX hostname OSPF-MIB::ospfIfTable
End of MIB

Kind regards,
Michał

#6

It is very likely that I did this wrong, but when I ran snmpwalk I got:

snmpwalk -v3 -l authPriv -u *** -a sha -A *** -x aes -X **** -M /opt/librenms/mibs -m OSPF-MIB::ospfIfTable 172.17.2.7

MIB search path: /opt/librenms/mibs
Cannot find module (ospfIfTable): At line 1 in (none)
SNMPv2-MIB::sysDescr.0 = STRING:
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.12356.106.1.4486
SNMPv2-MIB::sysUpTime.0 = Timeticks: (725399924) 83 days, 22:59:59.24
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: sw48-user
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 78
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00

and then pages of per interface data

edit: I tried rearranging my command like to be like the one in the above link and got this:

snmpwalk -v3 -l authPriv -u **** -a sha -A **** -x aes -X **** -M /opt/librenms/mibs 172.17.2.7 OSPF-MIB::ospfIfTable
SNMPv2-MIB::sysDescr.0 = STRING:
Error: OID not increasing: OSPF-MIB::ospfIfTable
= SNMPv2-MIB::sysDescr.0

#7

@LunarStationAlpha that is some fancy snmp server behavior you are getting from your device.
Instead of returning the OSFP-MIB::ospfIfTable (or that it doesn’t exist), it just sends other data… And the bottom one looks like it tried to get stuck in a loop.

#8

Ha! well I like to fail in new and original ways…
Just fyi, I updated this morning to (#13534), and the (#13530) OSPF patch did not fix the issue for fortinet switches. Still show up as unpolled devices if the OSPF poller module is enabled.

#9

I just updated my LibreNMS to 21.11.0-20-gf12d1f98c and I am seeing the same thing on my Fortinets.

#10

FYI - “Skip invalid OSPF data (#13547)” Appears to have fixed this issue
all fortinet switches are polling properly even with the OSPF module enabled.
I believe this issue can be closed.
Thanks for your help!

#11

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.