OSPF trap correlation

Dear all,

We have configured one trap coming when a node is losing his adjacency to the neighbor = OSPF Nbr down.

Then another one when the Adj. is coming up again = OSPF Nbr up.

We have some false positive and we would like to avoid getting an alarm for every up/down during 30 sec.

Ideally we would like to dampen the OSPF Down during 3min and check if we receive the OSPF Up during this time. If not we can generate the event and automatic action OSPF Nbr down.

I did some testing with dampening and suppression, but doesn't work as expected...

Any help would be greatly appreciated

Thanks a lot 

  • Hi,

      Without knowing the full trap details I can't be sure this will work, but the general approach to this sort of scenario would be to

    1) Configure the "down" trap to be dampened for x seconds

    2) Configure a Pairwise entry to pair and delete/close the down and the UP traps

      In this way if the up trap comes in while the down is dampened then the two will be paired and deleted or closed.  If it does not then the down trap will be displayedin the UI.  If you configure the pairwise with a "0" then when the UP does finally come in it should be paired with the down and then either delete or close it.

      Is this workable for you given the traps and the varbind payloads they carry?

      All the best

    Dave Y

  • Hi Dave,

    Thanks for your prompt reply, here's the details of the config (images). Please note that the down trap and up trap is the same, only a variable is different. I assume that a payload filter can do the distinguishment here?

    Trap down : ciaName = . CiaValue = 8

    Trap up: ciaName = . CiaValue = 1

    But should I do the dampening on the SNMP Trap configuration > Dampening tab or Node Settings tab > My node group > Open then > Dampening tab ?

    Thanks a lot for your reply



  • Ok this what I did for pairwise correlation (images), not sure if this is coherent here...

    Dampening was enabled on the SNMP Trap config > Node Settings > MynodeName > Dampening with 3min.




  • Hi there,

      Where you have set the dampening configuration is correct.  If you have configured a node group entry within the trap configuration that is process the trap then you should dampen within that area.  If there is no node group configured, or if the trap source is not in the node group then you would dampen within the default configuraiton - the top layer.

      The configs look good.   You are matching on ospfNbrState and this variable OID ends with the .6 and you should not include any instance, which you have not.    Similarly in the "Matching criteria" this further qualifies the match which by default is for the same node, and where you may need to compare more varbinds to ensure you get the right pairing  e.g for link Up/Down you need to match the ifIndex varbind.    

      Looking at the oid you have provided in the matching criteria this is wrong.  This is the trap OID, for the ospfNbrStateChange and  so is not correct.  It needs to be a varbind OID that has the same value in both the traps and is unique to the pair. 

      All the best

    Dave Y

    Dave Y

      All the best

    Dave Y

  • Thanks for your hints.

    I attached here the values from the 2 traps (first is down =1 second is up = 8)

    What can I use for the matching criteria first entry (OID?)? it will be always the same coming from the same node for a up/down but we can have other nodes sending similar traps.



  • Hi,

      Firstly you can take as a given that the traps being evaluated will have been sent from the same device - this is done by pairwise.   All you need to do is to match the Down (1) and the Up (8) in a way that ensure the Up is referring to the Down.  So in the examples you have the OIDs

     So you coulkd use either .1 or .3  which relate to the neighbour.  If you find the same neighbour may have the same IP but a different rtrid or vice versa then you could use both in the matching criteria form so that both have to be the same.

      All the best

    Dave Y

  • Thanks for your reply.

    So in my case the neighbor will be the same for a given down / up incident.

    We have a router A wearing and losing his neighbor router B wearing for i.e.

    My attempt here is to :

    1. Ensure if the router A loses router B NNMi wait for the up trap for 3min. After that delay (if no up even is received) the trap is handled and a automatic action is triggered, when a up trap is received for the same router A & B she is immediately handled (no 3min delay), closing the correlation.
    2. If before the 3min the same neighbor (router B) restored the link (up trap), we simply correlate and do nothing.

    So in that scenario do I need to add something else in the matching criteria than for first and second incident criteria ? (I'm not sure if we need to have several...).

    Below how I configured it :

    Above here do I need also to put the pairwise to 3min like the dampening or let it as is ?



      Okay I think we are nearly there.

      So what you should have in the pairwise configuration is

    First Incident Payload filter:    . CiaValue = 8

    Second Incident Payload filter:  . CiaValue = 1

    Matching Criteria: (ospfNbrIpAddr)   and (ospfNbrRtrId)

    In the Duration field I would put a "0"  as this means "match the current parent to the last open child received.  In this way you shouldn't have any timing issues because of windows closing before the correlation occurs since you want to match the Down and the Up however long apart they are.

      Can you test this out and see if it works?

      All the best

    Dave Y

  • Thanks again,

    For the matchin criteria it should be like the first picture or the second ? :

    Thanks again


      The first one.   Each row is an entry so you want to match the value of the .1 variable with both traps and then if these match, the .3 variable needs to be matched.  In the second configuration you would be matching the value of the .1 variable in the down trap with the .3 variable of the up trap and of course they won't match - as you are matching an IP address to an ID.

      All the best

    Dave Y