On Tue, 2005-01-25 at 09:08, Andrew Hood wrote:
> At present forwarded traps appear to come from the forwarder rather than
> the original source.
>
> For v1 traps, should it copy the trap source address to the agent
> address if the agent address is zero?
Request for clarification:
By "v1 trap", do you mean the incoming trap (from the original
source to the forwarder), the outgoing trap (from the forwarder
to the trap receiver), or both? (And similarly for "v2 trap")
If you're talking about an incoming v1 trap being sent on as
a v2 trap (or vice versa) then RFC 3584 seems reasonably clear
on the matter:
3.1. Translating SNMPv1 Notification Parameters to
SNMPv2 Notification Parameters
(4) The SNMPv2 variable-bindings SHALL be the SNMPv1
variable-bindings ... [with] three additional
variable-bindings ... appended.....
The name portion of the first additional variable
binding SHALL contain snmpTrapAddress.0, and the value
SHALL contain the SNMPv1 agent-addr parameter.
[which might well be 0.0.0.0]
3.2. Translating SNMPv2 Notification Parameters to
SNMPv1 Notification Parameters
If the translation occurs within a proxy application, the
proxy must attempt to extract the original source of the
notification from the variable-bindings. If the SNMPv2
variable-bindings contains a variable binding whose name is
snmpTrapAddress.0, the agent-addr parameter SHALL be set to
the value of that variable binding. Otherwise, the SNMPv1
agent-addr parameter SHALL be set to 0.0.0.0.
So it looks as if the agent address information (the agent-addr
field or snmpTrapAddress varbind) should be taken from the
contents of the incoming trap, and *not* determined from the
transport over which the trap arrived.
If you're talking about an incoming v1 (or v2) trap being sent
on using the same version, then the situation is not quite so
clear. My immediate reaction is that a v1 'agent-addr' field
should be left unchanged (on the grounds that the original
notification generator will presumably have set it appropriately
in the first place). And the description of the snmpTrapAddress
MIB object is specifically phrased in terms of SNMPv1 traps, so
it probably shouldn't be added when forwarding a v2 notification.
But I can't immediately spot any RFC text to back up these
positions, so that might be open to re-interpretation.
Dave
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
