[AGENT++] [Fwd: RE: snmpv3 - question on usm use of engine_id , time window]

[Jochen Katz]

OK, forwarding it as inline...

-------- Original-Nachricht --------
Betreff: 	RE: [AGENT++] snmpv3 - question on usm use of engine_id , time
window
Datum: 	Tue, 6 Oct 2009 19:52:12 -0500
Von: 	Anurag Jain <anuragjain026 at hotmail.com>
An: 	<katz at agentpp.com>, <agentpp at agentpp.org>
Referenzen: 	<BLU123-W42569F6909EFC61D3CAD21F9800 at phx.gbl>
<BLU123-W249B0AFE18252159EBEB23F9D60 at phx.gbl>



Thanks for the reply..

On scenario TWO below we tried using v3MP::remove_engine_id  which
delegates to USM::remove_engine_id
and clears the usm_time table as well , so it has the same effect as the
USM::remove_time_information. It
does not solve the problem , could you suggest another way or workaround
to clear the internal state per enginedID so as to make this work.
Note: the error via wire shark seems to indicate  that the agent is
sending usmStatsNotInTimeWindows report errors.

we are using : SNMP++v3.2.21a , could this have been fixed in a later
release ?



> Date: Tue, 29 Sep 2009 21:25:41 +0200
> From: katz at agentpp.com
> To: agentpp at agentpp.org
> Subject: Re: [AGENT++] snmpv3 - question on usm use of engine_id ,
time window
>
> Hi,
>
> > For the above purpose we extract the engine_id by calling function
> > v3MP::get_from_engine_id_table , in case this function does not
> > return success we call the second version of add_usm_user which does
> > not require engine_id.
> >
> > Is the above fallback recommended and is this approach to adding
> > users with and without engine_id as a fallback recommended , if not
> > when should the function without engine_id be used and safely too ?
>
> your approach is OK. You only will have a problem, if the added user has
> different passwords on the agents you want to get the engine id from. In
> this case you will have to
> 1) add user with password of agentA
> 2) issue a request to agentA
> 3) add/replace user with password of agentB
> 4) issue a request to agentB
>
> You can avoid this through creating a special Snmp object that you only
> use for calling engine_id_discovery().
>
> > Could the use of add_usm_user without engine_id create problems with
> > key localization across multiple agents with same security profile ?
>
> If "same security profile" is "same password, same auth and priv
> protocols", then you won't have any problems. In fact, the intention
> when creating the API was, that the add_user function without engine id
> is the recommended function to use and snmp++ does the engine id
> discovery process automatically. But as you already know, this only
> works, if one user has the same password, auth and priv protocol on all
> agents.
>
> In an environment where a user has different profiles on the agents I
> would recommend using the engine_id_discovery() function, but your
> approach is also OK.
>
> > 2. On another note we have another scenario where the the agent to
> > which successful communication was established and worked fine until
> > a reboot of the agent occasionally throws the time window out of
> > sync causing communication failure , in this case how can the v3
> > manager resync and/or with regards time- window checking /timeliness
> > checks ?
>
> Normally the manager should automatically resynchronize to the agent
> after the reboot. If this does not happen, most likely the agent has a
> bug. The agent either:
> a) resets the engine boot and engine time values to zero
> b) does not increase the engine boot value
>
> You could use Wireshark to check what applies and ask the author of the
> agent to change this behaviour.
>
> > Can the v3 function USM::remove_time_information be used for
> > resetting internal time related state and thereby forcing a resync ?
>
> Yes, this can be used as a workaround.
>
> Regards,
> Jochen
> _______________________________________________
> AGENTPP mailing list
> AGENTPP at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/agentpp