Only send notification when a NEW BGP sessions goes down or up

Help
1

I am using the default Alert Template for sending notification when one or multiple BGP sessions go down.
Now, when a new BGP session goes down, I get a notification e-mail titled ‘BGP session down - got worse’. When a BGP session goes up, I get a notification e-mail titled ‘BGP session down - got better’.
While this is very confusing, the biggest problem I have it is hard to distinguish what is the latest session that went down or up after the previous alert.
Would I need to code this myself or is there an easier way already built in LibreNMS?

2

So the real question would be: “How would I have LibreNMS only sent a notification when, after a new poll, one or multiple BGP sessions went up or down?”.
Sessions that have been down for a while are also sent in the notification mail, which pollutes the entire message because I have to distinguish them now.

3

Basically, this is not possible in the current LibreNMS implementation. You would have to shut a bgp session that is down (and explected to be down). This is usually a good practice anyway, but this is in fact mandatory if you want to have a “clean” alert window in LibreNMS.

4

I would have thought this would be the case :frowning:

5

We are all open to contributions in order to change that. But as this is a structural design of the alert template to avoid duplication, this would be a lot of work (and probably not appropriate) to change this.

Again, I would suggest to look at this on another angle : It is never a good idea to keep an alert in the Alert tab forever. If a BGP peer is down, then I would rather shut it properly, so the alert goes.
You can also make 2 different alerts (one for your transits, usually a low amount) and one for your peers (in IX, usually a lot, but usually not a problem to loose one or 2). That would give you the critical alerts (when a transit is down, which should never happen) and peers can be only warnings, which will get worse or better, but will at least be separated from the critical ones).

6

Thanks for your clear answer @PipoCanaja !
I’m already looking at SNMP traps, which might be a more specific type of monitoring that we can use.

7