Re: SNMP Trap, Management event and Dampening (232 Views)
Reply
Occasional Contributor
jc8780
Posts: 3
Registered: ‎05-17-2014
Message 1 of 2 (270 Views)

SNMP Trap, Management event and Dampening

Hi,

 

We are using NNMi 9.20 with patch 4 installed (on RHEL) and have some quetions on linkdown trap.

 

In Management event configuration, it looks like a "one minute" default dampening is set for InterfaceDown event.

When switch port is down, we get the linkdown trap and, after around 1 minute, we see an event generated by NNMi.

We tried to disable dampening and would like to see the management event being generated without too much delay, but we still get the event after around 1 minute.

If we test the InterfaceDisable event, we get the event generated by NNMi after around 2 or 3 seconds when the interface is disabled. (by default, no dampening is set for linkdisable event)

 

So, our questions are:

 

1) Is there any reason why NNMi have a default 1 minute dampening delay for InterfaceDown event ? Or why NNMi intentionlly delays to publish the Interfacedown management event after it gets the linkdown trap ? Is NNMi waiting for causal engine to analyse/confirm/generate the result ?

 

2) When NNMi gets the linkdown trap, will it trigger status poll to confirm link status or it will wait for next polling cycle?

 

3) Why NNMi behaves differently when it gets interfacedisable or interfacedown trap with dampening disable ? Does NNMi think "interfacedisable" is manually configured and publish it directly without too much analysis and spend more time on "interfacedown" event to confirm the link status to avoid generating unnecessary link flapping alarm ?

 

Appreciate for any input or comment on the above.

 

(In attached file, you can see some interfacedisable or interfacedown event)

 

 

 

Honored Contributor
AndyKemp
Posts: 751
Registered: ‎05-17-2010
Message 2 of 2 (232 Views)

Re: SNMP Trap, Management event and Dampening

1. SNMP traps are treated as hints, not fact. It verifies using its knowledge of the topology and status of other onjects in its inventory.

 

2. It triggers an object status poll, but its sent to the end of the existing queue.

 

3.  Interface disabled requires a bit more thought since its reading the IF-MIb state for one of three Administration values: Enabled, Disabled, Testing.

Have a nice day :)

Andy Kemp,  CISSP
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.