I’d like to monitor the ARP table counts of my coreswitch with a nagios plugin and it’s been already done. But there is a problem now: the counts from SQL is currently much more than the coreswitch. (SELECT count(*) from ipv4_mac where device_id = “CORESWITCH’s ID”)
Will the count from ipv4_mac be in sync with coreswitch after running “discovery.php -h CORESWITCH” or it just update the ARP table? It seemed to be synced in version 1.33 and now just having more in the table in 1.36.
Any information would be appreciate, thanks.
PS. I’ve added a cronjob and it will do the coreswitch discovery in every 1 min. and even did it manually right away.
Component | Version
--------- | -------
LibreNMS | 1.36
DB Schema | 232
PHP | 7.0.22-0ubuntu0.16.04.1
MySQL | 10.0.33-MariaDB-0ubuntu0.16.04.1
RRDTool | 1.5.5
SNMP | NET-SNMP 5.7.3
Finally got an exact clue here:
the old ARPs are NOT released/deleted from ipv4_mac
so that the counts get more and more by time. It seems like a bug which would make the ARP search totally wrong. Any solution for this bug?
That’s already fixed in 1.36.
We truncated the table on update as well. If that’s not happened for you feel free to do it manually but code should now be fixed.
Cool, should I use discovery-wrapper.php or discovery.php -h all to trancated it and update? It will be nice to have a cronjob more frequently (like once per hour) if ARP table monitoring is important for me.
You have truncate the table on the database.
No, the table was totally empty correctly after upgrade. So originally it runs discovery-wrapper.php every 6 hours. How does it avoid this issue itself? I didn’t see any actions of delete or truncate in discovery.php and daily.sh. I just did a cronjob to do discovery and let the ipv4_mac keep growing.
I was saying if you wanted to do it yourself then you would need to run the command in the db. I wasn’t talking about the update.