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")
The trap is forwarded in whatever form it was received. Are you implying snmptrapd's forward directive can be persuaded to convert incoming traps to a single version? I can't see that in the man pages.
>
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.
I have to proxy traps through a number of firewalls. Short of installing Netview inside each DMZ and having it use it's own mechanisms to get through the firewall the agent address MUST be set otherwise the forwarder becomes the trap source. It doesn't make much sense for the *nix/Windows box running the proxy to be seen as being a Cisco router/switch, etc. and it totally misleading to the support groups as to where the problem is.
If the original trap *had* an agent address I want it left alone. If it didn't, I want the source address because that it the best approximation I can make.
The contention that the generator should have set the agent address is reasonable. Unfortunately that isn't always the case.
Andy
--
There's no point in being grown up if you can't be childish sometimes.
-- Dr. Who
------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
