Re: clarification request: V2->V1 Trap conversion

Juergen Schoenwaelder <[email protected]>
Newsgroups gmane.ietf.snmpv3
Message-ID <[email protected]>
>>>>> Dave Shield writes:

Dave> When converting an SNMPv2 notification PDU into an SNMPv1 trap,
Dave> the original varbind list will include varbinds for sysUpTime,
Dave> snmpTrapOID and snmpTrapEnterprise.  Section 3.2 RFC 2576
Dave> describes how to use these to determine the appropriate values
Dave> for the SNMPv1 trap header fields, and then says:

Dave>    (6) The SNMPv1 variable-bindings SHALL be the SNMPv2
Dave> variable- bindings.  [... mumble mumble Counter64 mumble ....]

Dave> This variable-bindings list would appear to still include the
Dave> sysUpTime, snmpTrapOID and snmpTrapEnterprise varbinds.  (Or at
Dave> least, I can't immediately spot anywhere that says these
Dave> varbinds should be removed).  The effect is that this
Dave> information effectively ends up being duplicated.  Is this
Dave> correct ?

Well, RFC 1215 says in section 2.1.2:

   The VARIABLES clause, which need not be present, defines the ordered
   sequence of MIB objects which are contained within every instance of
   the trap type.  Each variable is placed, in order, inside the
   variable-bindings field of the SNMP Trap-PDU.  Note that at the
   option of the agent, additional variables may follow in the
   variable-bindings field.

The text says that optional varbind can be appended - not that they
can be prepended. I would not be surprised if there are deployed trap
receivers that do expect that for example ifIndex is in the first
varbind in a linkDown or linkUp trap. So to be safe, I would recommend
(whether that is written down or not) to remove the snmpTrapOID and
snmpTrapEnterprise varbinds when sending SNMPv1 PDUs. In fact, this is
what I implemented in the scotty package does a notification must be
shipped via SNMPv1.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.