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.
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 emking@lexmark.com