This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Mute BGP neighbor alerts during ISP maintenance.

Hi All,

We have BGP neighbor status alert, whenever a bgp neighbor goes down it will trigger alert. When ISP planning maintenance our network team put the interface in maintenance mode and they don't want to get any alert during the maintenance.

Network team don't want to put the entire node in unmanaged state, they only want to put the interface in unmanage state. someone suggest me alert condition for this scenario.

Thanks,

DN

  

  • I don't believe there's a way to mute alerts / unmanage routing neighbors. You can mute and unmanage the interface but I doubt that would stop the routing neighbors down alert from firing.

    My bet is as you said, you'll need to build this into the scope, or trigger of the alert by creating a copy of the alert (if it's the out-of-the-box alert). Custom properties could help perhaps achieve this if applied to the interface that designate a custom maintenance window.

    Not sure though if the interface is the right spot for it though and if custom properties could be leveraged when referring to routing neighbors.
  • Instead of using "Unmanage," use "Mute Alerts" on the device.  All the polling still happens, just none of the alert logic is run.  That's probably your best solution.

  • Will try the custom property option.
  • Problem is my network team is not ready to mute the device. They only ready to mute/unmanage the interface.

  • That really limits your options, darn. I understand though.. even though that neighbor may be going down it may very well be serving other critical connectivity through it's other interfaces.

    I'll try and play around with an alert and see what I could come up with.

    This makes me wonder if there's a way to link the neighbor to the physical or virtual interface that's monitored on the node. If so it's (in theory) possible to turn this alert into a custom swql alert if the alert builder UI can't handle it.
  • Not sure if there's a way to do this natively in the alert builder UI but taking the SWQL from the neighbor down alert and editing it a bit, I think I have a working PoC for this that takes into account interfaces being muted for alerts. So all they should need to do is mute the alerts for the interface that the neighbor is connected on and presto.. You'd need to either create a new SWQL alert or copy the out-of-box alert and turn it into a SWQL alert to use this though.

    SELECT E0.[Uri], E0.[DisplayName]
    FROM Orion.Routing.Neighbors AS E0
    LEFT OUTER JOIN Orion.AlertSuppression AS E1
    ON E0.[Router].[Nodes].[SwitchPortEntriesAsSource].[SourceInterfaces].[Uri] = E1.[EntityUri]
    WHERE ( ( E0.[ProtocolOrionStatus] = '2' ) OR ( E0.[IsDeleted] = 'True' ) )
    AND ( ( GETUTCDATE() < E1.[SuppressFrom] OR GETUTCDATE() > E1.[SuppressUntil] ) OR ( GETUTCDATE() < E1.[SuppressFrom] AND E1.[SuppressUntil] IS NULL ) OR ( E1.[SuppressFrom] IS NULL AND E1.[SuppressUntil] IS NULL ) )

     
    There could be ways to clean this up a bit, and most definitely should be some more testing if you plan to use it but hopefully this can help.

    Good luck

  • We have a nearly identical need and I was very excited to find this query, but when I try to validate it a "query condition is not valid" error message is given.  (see screen capture)

    Has there been a change to the data table names or do you have a suggestion as to what I might doing wrong?

    We are on version 2020.2.1 HF2

    I would be very grateful for any insights you might have.  

  • So the primary issue is I created that swql query above for a routing neighbor entity not an interface as is in your screenshot. Secondary to that the custom SWQL alerts include and auto-add the whole SELECT ... FROM ... so you do not include the select or the from statements.