On Thu, 2005-01-27 at 22:49, David T. Perkins wrote: > 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?)
In terms of the SNMP specifications as they stand, determining the address is unnecessary. A non-IPv4 address would be represented by an agent-addr (or snmpTrapAddress) of 0.0.0.0. (I'm not quite sure whether the specs contemplate receiving a trap over IPv4/TCP, but it would probably be sensible to treat this as equivalent to IPv4/UDP). I'm wondering whether it might be useful to add a couple of extra varbinds to the trap payload, with syntax TransportAddress and TransportAddressType, to represent such a non-IPv6 address. I haven't checked the specs in detail, but if these varbind were added to the end of the payload list (but *before* snmpTrapAddress) then I think that ought to be valid. Most management applications would ignore them, of course. But at least the information would be there. > 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? <nods> That's a trickier situation, certainly. Inserting the IP address would allow the management application to get closer to the original source (and both the classic proxy itself and the network managers presumably knows that it is acting as such!) But I wouldn't want to defend adding such source information in all circumstances. Hence suggesting to Andy that such a feature should be configurable (and default to off). > 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. Unfortunately, that *is* what is specified as the correct behaviour, and we can't simply ignore that fact. > 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. But in the case of the "classic proxy" you mention, that would in fact be the correct device to poll. It would then be up to that proxy agent to query the real originator of the trap (using something other than SNMP). > 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. But I'm not suggesting adding an IPv4 transport address unless that is actually appropriate. (Witness also the idea of extra 'nsTrapAddressType/nsTrapAddress varbinds) 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 [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
