Hi LibreNMS Developer!
It would be nice to add a new field in table ‘bgpPeers’, called ‘bgpPeerState_prev’. So alerting on BGP State would be easier and more detailled. Thank you for this great project!
What’s your use case?
Hi @Satrio_Adi
I did update your text to use the right terms (field and table) wherever needed. I suppose you want to be able to detect a change of state instead of alerting on all non established peers.
But if you already disable all broken peers in your device, then only the established peers will remain, and you can then alert on any peer that is not established. That’s exactly what we do here, and it works beautifully.
What is the exact scenario that would require to add this bgpPeerState_prev ?
Yes, exactly what I need! alerting the changed state of BGP peers instead of send all non established peers.
where you disable the non established bgp state? in librenms server or in device?
In device directly. ‘neighbor xxxxxxx shut’ on Cisco for instance. Only peers that should be ‘established’ should be ‘no shutdown’. That way, you have no alerts coming in until a real issue arises.
Unfortunately, there is no way to grab the neighbor description in SNMP. That would have been a nice way to define some kind of criticity in the peers.
hi!
Unfortunately, we can do that 
Because we are an Internet Service Provider. Some of our customers have multiple ISP and peers, so we cant “shutdown” the “not establish” BGP peers.
any advice?
Yes, but if you have a peering, I suppose you want it “established”, right ? So if it is not established, you want to get an alert for it. And if it is supposed to be down and want to avoid alert (because it is expected to be down) then you can shut it down. And if it will stay down for a while (because of a maintenance) you can then acknowledge the issue.
I don’t really see what would be so different with a new field and prev state :
- Comparing prev_state and current_state would only alert on a peer that was once up, which is not the case right now.
- Alert would disappear after next poll (because prev_state and current_state would get equal), but that is not a good thing (you don’t want your alerts to disappear, you want to have them until solved).
Hi guys,
I have the same use case as Satrio_Adl,
Did anything ever come from this?
Cheers
Andrew
So far no change. The request is in fact not defined properly and creating this field would not really help either.
bgpPeerState_prev would only allow to detect a down peer that was once up. Right now, even a peer that was never up is detected. And the bgpPeerState_prev would be equal to bgpPeerState after 1 more poll, which would remove the alert.
What is your usecase that cannot be handled with current scheme ? @AJJ