Re: Multiple entities - snmpv3

Not sure what you mean by entity but ...

Most of the network boxes I see these days are chassis with blades
that slot in to provide hub functions, switch functions, router
functions with an interconnecting backplane and hot plugging so I can
change the functionality to meet changing requirements.  I only have
one backplane, one physical lump, one management module (plus backup),
one set of console ports so I want to have one SNMP engine, one set of
security and access/transport information that supports multiple MIB
module instances, a separate MIB II for each hub or router or switch
instance (or anything else that might come along).

That to me is why I need multiple contexts (although I have never
heard if that is why the SNMPv3 architects specified them:-).

The bad news is that all the boxes I see are SNMPv1; and I am not
holding my breath.

Tom Petch

-----Original Message-----
From: Sreekakulam Venkata Siva Prasad Gupta <[email protected]>
To: [email protected] <[email protected]>
Date: 23 October 2002 10:08
Subject: Multiple entities - snmpv3


>Hi,
>
>    We are right now working on the SNMPv3 product.
>  We are implenting SNMPv3 by standards RFC 2571-2576.
>  I have some queries in the RFC.
>
>  1) can command responder of one entity ( contextEngineId A)
>  register with other SNMP Entity ( contextEngineId B)?
>  If the answer is "yes", what is purpose of registering with
>some
>  other entity (Differnt context Engine Id)?
>
>  If the answer is "no", why the command responder should
>provide
>  the contextEngineId (if it is not registering with the other
>  contextEngine Id) while registering?. I feel the pdutype is
>  sufficient for registration.
>
>  2) What is the advatage of having multiple entities in a
>single
>  managed node?
>
>  3) what is the purpose of having multiple command responders in
>a entity?
>
>  Expecting the answers eagarly for the above.
>  Thanx in advance.
>
>  Thanx & regards
>  Venkat
>
>
>