[SNMP4J] v3 EngineIDs, RFC, and 'Administrative Domain'

[Frank Fock]

Hi Scott,
Please do not mix up the security engine ID with the context engine ID of an agent. The are totally different. The (security) engine ID must be unique world wide. 
With some effort you might be able to use two separated USM instances with two Snmp instances to exchange SNMPv3 messages with two agents with the same engine ID.
In any case, I do not recommend this approach, as it will create more problems than it solves in the long run.

Best regards,
Frank Fock 


Scott MacKay <scottmackay at yahoo.com> schrieb:

>Hi there...
>
>I have a non-optimal situation in which I believe 2 switches I want to interrogate have the same engine id which is naturally causing problems when trying to access them using SNMPv3.
>After checking around different threads of discussion it looks like it relates to the engine id being used as the hash in a singleton class (USMTimeTable?).  Since my java application is the one which contacts the difference services, even though that is done in different threads with different allocated resources, I expect the library is still combining things to cause problems.  After following the details I can fully understand it as it has been repeated numerous times that the engineid is supposed to be unique within an administrative domain.  I even did come across an old.nabble discussion about engineids and defaults used and the like and most certainly want to stay as compliant with RFC as possible.
>
>The one thing I was wondering about though is, with reference to the RFC3411 statement 'Within an administrative domain, a contextEngineID uniquely identifies an SNMP entity'.  Is there any way in SNMP4J to set up separate 'administrative domains' for the context of engine id management?  
>
>-Scott MacKay
>_______________________________________________
>SNMP4J mailing list
>SNMP4J at agentpp.org
>http://lists.agentpp.org/mailman/listinfo/snmp4j