07-15-2014 10:04 AM
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)
07-17-2014 06:08 AM
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.
Andy Kemp, CISSP