On 18/05/07, John Giaccotto <[EMAIL PROTECTED]> 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 [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
