Re: Where are Net-SNMP generated traps documented?

On Thu, Jan 28, 2010 at 11:40 AM, Dave Shield <[email protected]>wrote:

> On 28 January 2010 16:31, Fulko Hew <[email protected]> wrote:
> > But nsNotifyShutdown is defined as { netSnmpNotifications 2 } which works
> > out to be (in my books):
> >
> > ... netsnmp (8072).netSnmpNotificationPrefix(4).netSnmpNotifications(0)
> >
> > I never saw that trailing '.0'.
> > Am I missing something in my interpretation?
>
> Please re-read the specification for co-existence between SNMPv1
> traps and SNMPv2 notifications.   In particular, RFC 3584 section 3.
>
> This intermediate '0' is the approved mechanism for ensuring traps
> can be reliably converted between different versions of SNMP.
>

It seems as though I _did_ miss something.  :-(
Let me see if I get my interpretation correct...
Can someone please confirm it?

There are two issues:
1/ MIB definition, 2/ PDU transmission

MIB definition
--------------

In the case of MIB definition, we want to discriminate between SMIv1 and
SMIv2.

When rewriting an SMIv1 MIB into SMIv2, the OID is defined with
an intermediate .0 between the enterprise value and the trap ID.

When writing a SMIv3 NOTIFICATION_TYPE from scratch, (not when
up-converting)
you _do not_ include the intermediate .0 ???

Ie. the intermediate 0 indicates a translated definition.

PDUs
----

When an NOTIFICATION TYPE is sent in an SNMP V1 PDU:

a) if (2nd last number in the OID == zero)
     'enterprise' field is the everything except the last 2 numbers in the
OID
   else
     'enterprise' field is the everything except the last number in the OID

b) the 'specific trap' field is set to the last number of the OID.

c) the 'generic-trap' field is set to 'enterpriseSpecific'


Example:

Fulko's trap in SMIv1:

    fulko        OBJECT IDENTIFIER ::= { enterprises 99999 }
    fulkoTraps   OBJECT IDENTIFIER ::= { fulko 1 }

    alcLineError TRAP-TYPE
        ENTERPRISE      fulkoTraps
        VARIABLES       { alcLineIfIndex, alcTrapReason, rs232PortIndex }
        DESCRIPTION
            "omitted for the example"
    ::= 1

If I were to re-write/migrate my existing MIB file into SMIv2 format,
I'd have to rewrite it as:

    fulko             OBJECT IDENTIFIER ::= { enterprises 99999 }
    fulkoTraps        OBJECT IDENTIFIER ::= { fulko 1 }
    fulkoTrapPrefix   OBJECT IDENTIFIER ::= { fulkoTraps 0 }

    alcLineError NOTIFICATION-TYPE
        STATUS        current
        OBJECTS       { alcLineIfIndex, alcTrapReason, rs232PortIndex }
        DESCRIPTION
            "omitted for the example"
    ::= { fulkoTrapPrefix 1 }

So even though the OIDs for each _appear_ to look like;:

TRAP:         1.3.6.1.4.1.99999.1.1
NOTIFICATION: 1.3.6.1.4.1.99999.1.0.1

the received PDUs (when sent to an SNMPv1 trap receiver)
in both cases would be the same.  Ie.

enterprise:    1.3.6.1.4.1.99999.1
generic-trap:  enterpriseSpecific (6)
specific-trap: 1

Ie. the intermediate .0 magically disappears during PDU creation
when targeting an SNMP v1 receiver.

Secondly, when sent to a SNMP v2 (or v3) capable receiver...
I don't know yet what I'll see (on the wire), I haven't tried it yet.

Fulko

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

_______________________________________________
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