Bob -
Thanks for setting us all straight on the details of this. I tend to gloss
things over.
Your technical clarifications are noteworthy, and thank you for clarifying what
I confused. But perhaps all we disagree about is a semantic difference, and
maybe, the utility of it all.
A V2 inform is certainly like a trap. And it certainly plays the same role.
But if the SNMP type is "a7" and not "a4", then it is not a trap, in my book.
That's what I meant when I said that, technically speaking, there are no traps
in V2. A strictly V2 agent (which no network management vendor would provide)
would then have to reject all V1 traps (a4) as errors, since a4 is undefined.
But you are absolutely correct that I incorrectly characterized what was in
V2. I should have been clearer about the fact that "notifications" is a
general term for unsolicited information from the agent, and that snmpV2-traps,
informs, and reports are more specific instances of that. Sorry I messed that
up. You did a good job of explaining it.
But I don't know what to say about agent vendors and snmpV2-traps. I have never
seen a real one nor been asked to work on a customer problem with one. So I
cannot, off the top of my head, vouch for how trapd handles them. It is one
thing to look at code and see that there is some checking going on for the
version type, and to handle things differently based upon that. But I cannot
say how it actually works in a real case. My guess, based upon what you say and
the RFC's, is that if the varbind list changes, then the formatting in
trapd.conf has to change, since there is a correspondence there. That's why I
advised originally that the thing to do was to print all the standard elements
($G $S $*) and see how it shows up.
But I said what I said about vendors not really buying into this, though
overstated (sorry, that is my fatal flaw), was because this was the very first
case of a V2 agent that has been brought to my attention in the four years I
have been doing this job. Perhaps my experience is too limited, or perhaps my
customers have already decided that we (NetView) won't do a good job with this
and so aren't implementing it, I don't know. But I have never worked on a V2
trap problem before. This may be the first.
But as long as we are on the subject, I suppose I should expose my bias here. I
have read some (not all) of the RFC's you mention and yet I am not convinced
about the utility of all this. And it is true that I work for a network
management provider (and we don't like to make code changes unless we have to),
but I frankly don't see any real reason, as opposed to an academic one, to go
from the a4 structure to the a7. Yes, it normalizes the SNMP PDU structure,
but that doesn't do the user any more good, so far as I can see. We will just
be changing code because the people who wrote the standard (mostly academics -
and I was one myself once) didn't do a good job the first time. That's like
rebuilding the house because the architect didn't like the way the blueprint
looked when he thought about it later. But that is just one man's opinion
(mine).
If you have a different one, I'd be happy to hear it.
Thanks
James Shanks
Tivoli (NetView for UNIX) L3 Support
Bob Natale <bnatale@acecomm.com> on 02/10/2000 12:37:44 PM
To: James Shanks <James_Shanks@TIVOLI.COM>
cc: NV-L@UCSBVM.UCSB.EDU (bcc: James Shanks/Tivoli Systems)
Subject: Re: trap daemon: can it receive SNMPv2 and SNMPv1 traps?
Hi James,
>First, technically speaking, there are NO traps in SNMP V2, because SNMP V2
does
>not recognize the trap designation (SNMP type a4) as supported.
SNMPv2c includes traps. It does not include v1 trap PDUs...which have
special formatting elements different from all other PDU types)...SNMPv2c
normalized the trap PDU to have the same format as all other PDU types,
and gave it a new PDU type code (a7). RFC 1908 gave initial info re how
to map between v1 and v2c traps; RFC 2089 later elaborated on that; and
now SNMPv3 provides the mapping in the "Coexistence" RFC (which I think
will be #2576 when it's foramlly publsihed as an RFC...it has already bene
approved as such by the IESG).
>SNMP V2 hatched a concept called "notifications" and another called
>"reports" which were meant to replace traps.
"Notifications" is simply a classifier for SNMPv2c traps and informs.
Informs are identical to traps in all respects except that the receiver
of an inform PDU must issue a response back to sender which simply
lets the sender know that the inform was received (not necessarily
acted on).
Reports are a new type of PDU that were defined with SNMPv2c but not
used until SNMPv3. They are intended to be "engine-to-engine"
signals and are not (typically) exposed to the higher layer apps.
>But no vendors, so far as I know, went along with this
>and thus traps are alive and well today.
Many vendors support SNMPv2c, including traps and informs.
>Second, trapd does have code to recognize when an agent says it is using SNMP
V2
>as opposed to V1, but there should be no difference in the varbind structure.
>They are still "type-length-value" with the encoding done by the same Basic
>Encoding Rules of ASN.1.
That's partly correct...yes, varbinds and varbindlists have the
same structure and encoding rules in SNMPv1/v2c/v3. However, as part
of the normalization of the trap PDU format in SNMPv2c, some of the
special fields from the SNMPv1 trap PDU were moved to varbinds in
the varbindlist of the SNMPv2c trap PDU. When mapping a v1 trap to a
v2c trap, certain aspects of the positioning/ordering of varbinds
in the v2c varvbindlist are mandated by the standards (see specs
cited above). NetView would have to make the correct mappings
(and I certainly have no reason to think it does not!).
Cordially,
BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale | ACE*COMM | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------
|