Re: Processing traps

Dave Shield <[email protected]>
Newsgroups gmane.network.net-snmp.user
Message-ID <[email protected]>
On 12 July 2010 17:19, Joseph L. Casale <[email protected]> wrote:
> So does it make sense to use .1.3.6.1.6.3.1.1.5.6 for both the enterprise-oid
> and the OID like this

NO!!!

The whole point about enterprise-specific traps is that they are
specific to a particular organisation ('enterprise').  Hence the name.
My idea of what trap #23 represents will be different to your idea
of what trap #23 represents.

So the enterprise OID is used to identify whose set of enterprise
specific traps is being referred to.   If you suddenly start using a
standard OID for this, you're completely undermining the whole
mechanism.


> snmptrap -v 1 -c public nms.domain.com .1.3.6.1.6.3.1.1.5.6 "" 6 23 "" \
>        .1.3.6.1.6.3.1.1.5.6 s "text..." \
>        .1.3.6.1.6.3.1.1.5.6 s "text..." \
>        .1.3.6.1.6.3.1.1.5.6 s "text..." \

It's then doubly wrong to re-using the enterprise OID (which acts as the
root of a set of trap definitions) as the name of the payload varbinds
for the trap.  How is the trap receiver meant to know what the payload
values represent?
  (Let alone what instances of a table originally triggered the notification)



> Or is there something more suitable for the OID if I am just needing to send
> text in the trap?

You need to define suitable MIB objects for the trap itself, and for each
payload value carried within the trap.   Then use these OIDs.

Dave

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.