Re: Where are Net-SNMP generated traps documented?

On 29 January 2010 19:28, Fulko Hew <[email protected]> wrote:
> In the case of MIB definition, we want to discriminate between SMIv1 and
> SMIv2.

When defining a new MIB file, you should write it using SMIv2.
The older form is effectively obsolete (unless you have ancient
software that only understands SMIv1).

The only reason to be concerned with SMIv1 is for dealing
with existing (ancient) MIBs.



> When writing a SMIv3 NOTIFICATION_TYPE from scratch,

There is no such thing as SMIv3.
There is only ancient SMI syntax (v1) and current SMI syntax (v2)

Don't get confused between the versioning of MIB file syntax,
and the versioning of SNMP protocol operations.   These are two
different things.


> When writing a SMIv3 NOTIFICATION_TYPE from scratch,
> you _do not_ include the intermediate .0 ???
>
> Ie. the intermediate 0 indicates a translated definition.

No.
When defining a new SMIv2 notification, you have the choice
of how to define the OIDs.   It is good practise to include the
intermediate 0 instance.
   This allows the notification to be sent as an SNMPv1 trap,
an SNMPv2c (or SNMPv3) trap, or an SNMPv2c/v3 inform.
And for this notification to be accepted, converted, forwarded,
etc without loss of information about what trap it is.




> 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

Correct

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

Correct

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

Unless this is one of the standard notifications, yes.




> Fulko's trap in SMIv1:

If it's a new MIB, then forget about SMIv1.
Define the MIB in SMIv2 - then everything should work fine.



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

An SNMPv1 trap does not have a single OID associated with it.
It has an (OID, integer) pair.
    (1.3.6.1.4.1.99999.1,   1)


> NOTIFICATION: 1.3.6.1.4.1.99999.1.0.1

Traps (both SNMPv1 and SNMPv2c/3) and Informs are all types of Notification.
The OID associated with an SNMPv2c/3 trap, or an Inform,
is the same as the OID of the Notification definition.
I.e.
    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.

When the (single) OID is split into an (OID, integer) pair, then the
intermediate 0 is omitted - yes.



> 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.

You'll see the full OID - 1.3.6.1.4.1.99999.1.0.1



Dave

------------------------------------------------------------------------------
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