Subject: Re: PMP> How to Resolve the Traps Compatibility Issue

From: Matt King <[email-masked]>
Date: Thu, 01 May 1997 13:11:35 -0400

Hi folks,

I agree that we should be able to verify some degree of compatibility by
each posting a specimen of trap data (Is this called "trap in the
cup?").  I have to disagree, however, that anything is broken in the
MIB.  As I read the MIB it is pretty clear on when traps should be send
and what they should look like.  What may be unclear is how to interpret
the TRAP-TYPE and NOTIFICATION-TYPE macros.  If clarification is needed
anywhere it is in those RFCs.  What follows is an explanation of why I
think out MIB is clear and correct as well as some background on SNMP v1
and v2 traps.  Maybe it should go in the FAQ if it is useful.

I got a little long-winded, but I hope this clears some things up for
those who are confused by the MIBs trap definitions.  

--Matt

------------------------------------------------------------------
Below is an excerpt from the Printer MIB with line number added for
clarity:

 1 printerV1Alert OBJECT-IDENTITY
 2     STATUS  current
 3     DESCRIPTION
 4         "The value of the enterprise-specific oid in a SNMPv1 trap
sent
 5         signalling a critical event in the prtAlertTable."
 6     ::= { prtAlert 2 }

 7 printerV2AlertPrefix OBJECT IDENTIFIER ::= { printerV1Alert 0 }

 8 printerV2Alert NOTIFICATION-TYPE
 9     OBJECTS { prtAlertIndex, prtAlertSeverityLevel, prtAlertGroup,
10              prtAlertGroupIndex, prtAlertLocation, prtAlertCode }
11     STATUS  current
12     DESCRIPTION
13         "This trap is sent whenever a critical event is added to the
14         prtAlertTable."
15     ::= { printerV2AlertPrefix 1 }

16 -- Note that the SNMPv2 to SNMPv1 translation rules dictate that the
17 -- preceding structure will result in SNMPv1 traps of the following
18 -- form:
19 --
20 -- printerAlert TRAP-TYPE
21 --     ENTERPRISE printerV1Alert
22 --     VARIABLES { prtAlertIndex, prtAlertSeverityLevel,
prtAlertGroup,
23 --                 prtAlertGroupIndex, prtAlertLocation, prtAlertCode
}
24 --     DESCRIPTION
25 --        "This trap is sent whenever a critical event is added to
the
26 --        prtAlertTable."
27 --     ::= 1

As for when to send traps.  Lines 4,5 and 25,26 state "sent whenever a
critical event is added to the prtAlertTable".  That seems pretty
definative to me.

------------------------------------------------------------------
As for what they should look like. Lets consider the v1Trap first.  

>From rfc1157, a v1Trap looks like this:

Trap-PDU ::= [4]
IMPLICIT SEQUENCE
{
    enterprise OBJECT IDENTIFIER,  -- type of object generating
                                   -- trap, see sysObjectID in [5]

    agent-addr NetworkAddress,     -- address of object generating trap

    generic-trap                   -- generic trap type
    INTEGER {
        coldStart(0),
        warmStart(1),
        linkDown(2),
        linkUp(3),
        authenticationFailure(4),
        egpNeighborLoss(5),
        enterpriseSpecific(6)
    },

    specific-trap INTEGER,         -- specific code, present even if
generic-
                                   -- trap is not enterpriseSpecific

    time-stamp TimeTicks,          -- time elapsed between the last
                                   -- (re)initialization of the network
                                   -- entity and the generation of the
trap

    variable-bindings VarBindList  -- "interesting" information
}

There are two basic categories of v1Traps -- generic and enterprise
specific.  The set of generic traps is comprised of 6 traps defined in
rfc1157.  All other traps, including those defined by standards-track
MIBs are considered to be enterprise specific.

The two categories of v1Traps use the fields in the Trap-PDU quite
differently.

For generic traps (those where the generic-trap field is not
enterpriseSpecific), the fields are as follow: The enterprise field
identifies the sysObjectID of the agent sending the trap.  The
agent-addr field identifies the IP address of the agent sending the
trap.  The generic-trap field identifies which of the generic traps the
trap is and is by definition not enterpriseSpecific(6).  The
specific-trap field is zero.  The time-stamp and variable-bindings are
as would be expected.

For enterprise specific traps (those where the generic-trap field is
enterpriseSpecific), the fields are as follow: The enterprise field
identifies the authority under which the specific-trap values were
assigned.  This generally corresponds to a specific MIB.  The agent-addr
field identifies the IP address of the agent sending the trap.  The
generic-trap field is by definition enterpriseSpecific(6).  The
specific-trap field identifies which specific trap as defined by the
authority specified in the enterprise field the trap is.  The time-stamp
and variable-bindings are as would be expected.

The Printer MIB alerts obviously fall into the category of enterprise
specific traps.

* The enterprise field is printerV1Alert as defined on line 21 (above). 
Lines 1-6 define printerV1Alert be { prtAlert 2 }.

* The generic-trap field is by definition enterpriseSpecific(6).

* The specific-trap field is 1 as defined on line 27 (above).

* The variable-bindings are prtAlertIndex, prtAlertSeverityLevel,
prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, prtAlertCode as
defined on lines 22 and 23 (above).

As a result, would expect all v1 Printer MIB traps to be of the form:
{
	enterprise =  { printmib prtAlert(18) printerV1Alert(2) }
	agent-addr = NetworkAddress
	generic-trap = enterpriseSpecific(6)
	specific-trap = printerAlert(1)
	time-stamp = TimeTicks
	variable-bindings =
	{
		prtAlertIndex.n.m
		prtAlertSeverityLevel.n.m
		prtAlertGroup.n.m
		prtAlertGroupIndex.n.m
		prtAlertLocation.n.m
		prtAlertCode.n.m
	}
}

------------------------------------------------------------------
Now, lets consider the v2Trap.  

In SNMPv2, all PDUs, including traps, have the same structure.  As such,
there are no specific fields to hold enterprise, generic-trap,
specific-trap, and time-stamp information.  Instead, this information is
encoded in the first two variables of the SNMPv2-Trap-PDU variable
bindings.  The first variable is sysUpTime.0 which takes the place of
the time-stamp field.  The second variable is snmpTrapOID.0.  Its value
is an OBJECT IDENTIFIER that encodes the values of enterprise,
generic-trap and specific trap.  For generic traps, it's value is {
snmpTraps generic-trap }.  For enterprise specific traps, it's value is
{ enterprise 0 specific-trap }.

Once again, the Printer MIB alerts fall into the category of enterprise
specific traps.

* The snmpTrapOID.0 variable is { printmib prtAlert(18)
printerV1Alert(2) printerV2AlertPrefix(0) printerV2Alert(1) } as defined
on line 15 (above).

* The variable-bindings are prtAlertIndex, prtAlertSeverityLevel,
prtAlertGroup, prtAlertGroupIndex, prtAlertLocation, prtAlertCode as
defined on lines 9 and 10 (above).

As a result, would expect all v2 Printer MIB traps to be of the form:
{
	sysUpTime.0 = TimeTicks
	snmpTrapOID.0 = { printmib prtAlert(18) printerV1Alert(2)
printerV2AlertPrefix(0) printerV2Alert(1) }
	prtAlertIndex.n.m
	prtAlertSeverityLevel.n.m
	prtAlertGroup.n.m
	prtAlertGroupIndex.n.m
	prtAlertLocation.n.m
	prtAlertCode.n.m
}

------------------------------------------------------------------
Below is an example of a trap the Lexmark printer sent as a result of
opening a cover.  The Lexmark implementation is v1 only so I have no
example of a v2 trap.

{
	enterprise = { printmib prtAlert(18) printerV1Alert(2) }
	generic = enterpriseSpecific(6)
	specific-trap = printerAlert(1)
	variable-bindings =
	{
		prtAlertIndex.1.13=13
		prtAlertSeverityLevel.1.13=critical
		prtAlertGroup.1.13=cover
		prtAlertGroupIndex.1.13=1
		prtAlertLocation.1.13=0
		prtAlertCode.1.13=coverOpen
	}
}

-- 
Matt King                                     Opinions are my own and
Staff Engineer                                    are not necessarily
Lexmark International, Inc.                          those of Lexmark
[email-masked]

---

From: Ron Bergman <[email-masked]>
Date: Thu, 1 May 1997 14:16:15 -0700 (PDT)

Matt,

Thanks for the excellent description of SNMP traps.  It agrees 100%
with my understanding of this subject with respect to v1.  (As far
as v2 goes, I am only implementing v1.)

I have found the SNMP documents difficult to understand and it is
always nice to see and independent conclusion that supports my own.
I hope others in the group also find this document useful.

Does anyone disagree with Matt?

I also agree that RFC1759 does not need to be changed and I support 
your recommendation to add this information to the FAQ.

	Ron Bergman
	Dataproducts Corp.