Re: clarification request: V2->V1 Trap conversion
Chris Elliott <[email protected]>
| Newsgroups | gmane.ietf.snmpv3 |
|---|---|
| Message-ID | <[email protected]> |
Dave,
Look at section 3, which states:
...
- A list of variable-bindings (VarBindList). This refers to all
but the first two variable-bindings in an SNMPv2-Trap-PDU or
InformRequest-PDU.
...
This is the list that 3.2 is refering to. So, from this it is clear that
this list does not include sysUpTime or snmpTrapOID.
There is not a snmpTrapEnterprise varbind. snmpTrapOID contains the
Enterprise, generic, and specific field information.
Chris.
On Thu, 21 Nov 2002, Dave Shield wrote:
> A quick question about an issue that's come up on the Net-SNMP coding list.
>
> When converting an SNMPv2 notification PDU into an SNMPv1 trap, the
> original varbind list will include varbinds for sysUpTime, snmpTrapOID
> and snmpTrapEnterprise. Section 3.2 RFC 2576 describes how to use these
> to determine the appropriate values for the SNMPv1 trap header fields,
> and then says:
>
> (6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
> bindings. [... mumble mumble Counter64 mumble ....]
>
> This variable-bindings list would appear to still include the sysUpTime,
> snmpTrapOID and snmpTrapEnterprise varbinds. (Or at least, I can't
> immediately spot anywhere that says these varbinds should be removed).
> The effect is that this information effectively ends up being duplicated.
> Is this correct ?
>
>
> The Net-SNMP master agent treats incoming AgentX notifications as if
> they were SNMPv2 notifications, so applies the same mappings when
> sending to SNMPv1 destinations. This means that subagent-generated
> notifications end up with the same duplication of information.
> I realise this isn't strictly an SNMPv3-related issue, but does
> this approach strike people as:
> a) reasonable
> b) valid
> ?
>
> Dave
> --
> Dave Shield [email protected]
> Dept. of Computer Science,
> Liverpool University, "He who brings [computers] on to his premises
> PO Box 147, should be absolutely liable ... for any mischief
> Liverpool, L69 7ZF that ensues." Haddock v. Computer 1578/32/W1
>
>
Chris Elliott CCIE# 2013 | |
Customer Diagnostic Engineer ||| |||
RTP, NC, USA ||||| |||||
919-392-2146 .:|||||||||:|||||||||:.
[email protected] c i s c o S y s t e m s