I need some help with creating an alert that matches the correct criteria for when an OSPF adjacency change occurs.
The trigger condition I am attempting to build is below, however it alerts on every OSPF enabled device, all of which only have full established neighborships.
ospf_nbrs.ospfNbrState != full
macros.device_up = True
I believe I am missing one more condition, but cannot seem to figure it out. I am trying to alert on any existing (or new) neighbor that goes down.
What am I missing?
Why not limit to only the devices you want?
I want all devices that have OSPF enabled to alert if there is a neighbor state change. Being that I want all my devices to meet this trigger condition, no limit is needed.
Just so I am clear, what would limiting this accomplish?
Hi Murrant,
I was hoping you had a response to above? I am not sure that limiting the scope is what I want to come to the alert that I am looking for.
Your help is appreciated.
I have no idea.
Only tip I can give you is to check the database to see what values are in there.
I have found a database table named āospf_nbrsā. OSPF adjacency states are stored here, but only when a neighbor is known. This is problematic if a neighbor goes down, because it is removed from the table entirely. Is there another table that I can reference that has previously known neighbors in it?
Did you ever get this to work?
Nope. No response from anyone able to implement the change request.
What do you mean by change request?
Sorry, I used the wrong verbiage entirely.
No one with the ability or willingness to code and create a pull request has responded to my feature request/suggestion.
Hi @tnielsen2
The neighbor is removed only at the next discovery process, which means you should get the alert between the issue and the discovery.
But at discovery time, only the online neighbors can be known. Unlike BGP, there is no neighbor definition in OSPF, most of the time, multicast hellos are used:
There is basically no way for the network device to know if a neighbor disappeared on purpose or if it is an issue/incident. And LibreNMS polls the device, so LibreNMS has no way to determine if it is an issue or a normal device turned off and removed from network.
The neighbor is removed only at the next discovery process, which means you should get the alert between the issue and the discovery.
I am not 100% clear on what you mean here. Are you telling me, if a neighbor goes down, and does not come back up that I should get an alert? Or am I misunderstanding? If this is the case, how do you write an alert that follows this criteria, without being specific to each neighbor or router?
I completely understand the thought behind LibreNMS polling a device, and how you wouldnāt know if it was an issue or a normal removal.
Without having to resort to a ton of custom alerts for each box, I would like a canned alert that keeps previously known neighbors in the table, but as showing down. I am remove intentionally downed neighbors from the database, which isnāt a problem for myself.
I am also open to ideas on how to alert on OSPF adjacencies going down, without having to write an alert for every OSPF router in my OSPF domain. It is very possible, and likely, I am not looking at the best way to alert on neighborships going down.
I just have a hard time believing that there are organizations using this tool without an easy way to get alerted on an OSPF neighbor going down.
Does the device emit an snmp trap for that? Perhaps that would be a better angle to alert from.
Concerning the standard LibreNMS alerting, I would go with something like this :
With this, I expect to get an alert whenever the status does not contain āfullā, and up until next discovery the alert will stay. After which, the peer will be removed from LibreNMS, which means the alert will disappear all by itself. That will give you some time to fix it, hopefully 
Iāll put that in my lab and see how it goes.
I want to say that I tried this already, because once the adjacency drops it disappears from the database. Because it isnāt in the database and no longer exists, how would it alert on something if it is gone from the table?.
I wont have time to try this in my environment until next week or two due to other projects. If it works in your lab, please report the findings.
Thanks!
SNMP traps are not configured in our environment, but I think I might just have to go along with a syslog alert, which I have done in the past for various other issues that are not pollable. 
Iāll check the code to validate if the adjacency is discovered during discovery process or only during poll. If only during poll, then actual LibreNMS cannot alert on it and code need to be written.
Iāll update you here.
I would also concur with previous discussion on this, the table does not log ādownā OSPF states, it looks like it just removes it from the table so there is no way to alert on it. Is there a workaround?
thanks!
No change so far. We need somebody to contribute this.
Thanks for your response. Unfortunately I do not know to code, this problem seem to be also applicable to ipsec-tunnel status, where anything that is not active is not recorded in the db.
