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. 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. > > > > 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 > ------------------------------------------------------- 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
