Re: Reducing Risk of Missing SNMP Traps

On 18/05/07, John Giaccotto <john.giaccotto@adeptra.com> wrote:
> ........We are generating
> traps from log4j appenders, Perl scripts and third party components that
> do not support the receiving of traps in response to INFORM messages.

Errr.... that doesn't really make sense.

If you have these various components that currently generate traps,
then the relevant question is whether they can be configured to
generate INFORMs instead. The TRAP and INFORM PDUs are both
examples of what SNMPv2 terms "notifications". Think of them
as alternatives, rather than one leading to the other.

So it's not a question of generating a trap in response to an inform.
Rather it's a matter of reacting to some external stimulus by
generating either a trap or an inform.


> My current thinking is that we could have traps sent to a central trap
> receiver in each datacenter. These central receivers would then resend
> the traps to the NMS using a TCP connection. Some custom processing
> would handle alerting us about any traps that could not be sent.

In general, the danger with traps is not that they can't be *sent*.
More that they are sent but never *received*. But sending them over
a TCP connection might well improve the reliability, yes.



> How do companies with multiple datacenters ensure that traps reach their
> destinations? Is it just through INFORM messages (a solution that you
> previously suggested), TCP connections or custom configurations such as
> what I wrote above?

Traditionally, traps have tended to be seen as *complementing* a poll-based
monitoring approach. It's generally regarded as being unwise to rely on
traps as the only way to report problems - rather they're seen as a more
timely reporting of something that would eventually be picked up anyway.

If nothing else, the trap generators could perhaps be queryable via SNMP
GET/GETNEXT requests to provide a count (or even a list) of the notifications
that they have sent. Matching this against the list of notifications received
would alert you to any problems.
See the NOTIFICATION-LOG-MIB (RFC 3014)


Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/...net-snmp-users