Re: clear traps

Dave Shield wrote:

>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.
>
>  
>
True, and not all our traps are in set/clear pairs, but there is increasing
customer/marketing pressure to go the set/clear route.  ("You sent a
coldStart but where's the coldStop?")

>>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
>  
>
Openview has a way to associate a severity with a trap at the mgmt station
but if you specify the severity in the MIB file it sets the default on load.
This saves time and effort for the Openview users who would otherwise
have to configure this for every one of your traps.  With this they can just
adjust the one's they want to change.  When you are receiving traps from
lots of different vendors' equipment you look for anything that saves time.

I pretty much agree with everything you've said above.  I've made many
of the same arguments, myself.  Unfortunately reason does not always
prevail in commercial environments.



-------------------------------------------------------
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
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users