Re: Enterprise trapquestion/send_v2trap API call

On 03/01/2008, Mike Ayers <mike_ayers@tvworks.com> wrote:
> > pivot3 OBJECT IDENTIFIER ::= { enterprises 25148 }
> > pvt3System MODULE-IDENTITY
:
> > ::= { pivot3 1 }
> > pvt3SysTraps OBJECT IDENTIFIER ::= { pvt3System 3 }
> >
> > pvt3DatabankDriveStateFailed NOTIFICATION-TYPE
:
> > ::= { pvt3SysTraps 7 }


> Note that this *notification* can not be converted to v1 format.
> If your target receiver is listed as v1, this will never be sent.


That's not actually true.
This notification *can* be converted to SNMPv1 format
(assuming "name" and "slot" are not Counter64 syntax objects),
and would be sent to an SNMPv1 trap receiver.
RFC 2576 (and subsequent revisions) describe this process.

The main problem with this MIB structure is that converting it into an
SNMPv1 trap, and then converting back to SNMPv2 format will result
in a *different* OID, and will no longer match "pvt3DatabankDriveStateFailed".


Wendy,
if the MIB definitions haven't yet been finalised, then it would be
sensible to insert an extra level:

pvt3SysTraps OBJECT IDENTIFIER ::= {pvt3System 3}
pvt3SysTraps0 OBJECT IDENTIFIER ::= {pvt3SysTraps 0}
pvt3DatabankDriveStateFailed NOTIFICATION-TYPE
:
::= { pvt3SysTraps0 7 }


The names aren't important, but you should always define SMIv2
notifications with '0' as the penultimate subidentifier.
This allows SNMPv2->SNMPv1->SNMPv2 conversions to work cleanly.


Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
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