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 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@agentpp.org
>http://lists.agentpp.org/mailman/listinfo/snmp4j
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
