David T. Perkins wrote:
HI,
Dave - your walkthough below sounds reasonable. I didn't check the RFCs to verify.
Here are the situations.... 1) When a v1 trap is received over a transport other than IPv4/UDP, how do you determine the source address? (for example, you received it over IPv6?) 2) When a v1 trap is received over IPv4/UDP, but was sent by a "classic proxy" (not an "SNMP Proxy") for a device that doesn't have an IPv4 address, then how do you determine the source address?
Choosing a scheme that leads management app developers to believe
that the value from the "agent-addr" field will ALWAYS provide
a network address is WRONG. Likewise, including a varBind for
object snmpTrapAddress.0 is also WRONG. You may ask is this
a problem with the protocol design and/or usage? And if so,
I would say it is. It is really nasty because with the so
called "trap directed polling" approach, when a manager
receives a notification (such as a trap), then the manager
should poll a device to determine the situation. Somehow,
a manager needs to correlate some "source info" in a notification
with a list of managed devices so that it can turn around
and poll the device. Many managers use just a network address.
THIS IS NOT ENOUGH. Thus, returning a IPv4 transport
does not solve this problem.
This is more or less why I started the thread. I am trying to provide network monitoring in an environment where I *must* proxy traffic. Consequently the source address in the packet when it arrives at the final destination will always be wrong. Hence I need an agent address. If that means that where the packet does not have one I must fake it by adding one, so be it. The best value to use is the source address, irrespective whether that is what the RFCs say is correct.
On Thu, 27 Jan 2005, Dave Shield wrote:
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.
--
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
