On Wed, 2005-10-05 at 12:48 -0700, John Hardin wrote: > I don't know how widespread this is, but I've dealt with a customer who > wants all traps to report the entrance or exit of a state.
Unfortunately not all traps fall into this model - whether your customer likes it or not. For example - 'authenticationFailure' traps are one-off events, and can't sensibly be regarded as either Set or Clear traps. 'coldStart' and 'warmStart' traps could perhaps be regarded as a sort-of "entrance" event, but won't necessarily have a corresponding "exit" trap (let alone a standard one). And 'egpNeighbourLoss' is another one-off event. In fact, of the original set of six standard traps, it's only 'linkUp' and 'linkDown' that fit with your customer's model. Of course, they are perfectly free to ignore any traps that they're not interested in. > They also want the trap varbind list to include a severity, > though there is no standard way to do this Correct. It would be perfectly valid to define a suitable MIB object to hold such a severity, and append this to the payload list of any notifications generated. But that would require updating the code of all the agents (or other notification generators) on their network - including any dedicated agents in network hardware kit. Quite honestly, I don't think this is practical. > Another way to associate severity with a trap, if the receiver > is using something like HP Openview, is to include a comment > in the trap's NOTIFICATION-TYPE block Though interpreting comments in this way is a proprietary mechanism, and couldn't be regarded as "standard". (Not to mention that most MIBs don't include such severity comments - quite understandably!) > Openview will interpret this and report the trap with the > appropriate color in the event log after it loads your MIB. Having said which, this is still probably the most appropriate mechanism in general - for the trap *receiver* to allocate the appropriate severity to a given trap, rather than try to piggy-back it onto the trap PDU. I'm not convinced that shoe-horning this into the MIB file syntax is a sensible way to achieve this, though. I'd suggest that 'snmptt' adopts a better approach - having a separate configuration directive to set up the mapping between a particular trap OID, and the appropriate severity. That way, you wouldn't need to mess about with adding non-standard stuff to various MIB files. All the local customisation could be held in the one config file - specific to the notification receiver. But however you address this problem, the severity is probably best set by the notification receiver, rather than by the agent. (All IMO, of course!) Dave ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ 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/listinfo/net-snmp-users
