[snmp] Need way to re-discover timeline info to recover fromusmStatsNotInTimeWindows

[Birgit Arkesteijn]

Hi Sharath,

We haven't got a date yet for a public release, sorry.

Cheers, Birgit

K, Sharath (Sharath) wrote:
> Thanks Birgit,
> This is exactly what I was looking for.
> I will test with this new code, and see how it goes.
> 
> Any idea when it will be available in a public release?
> 
> Thanks,
> Sharath
> 
> -----Original Message-----
> From: snmp-bounces at snmp.westhawk.co.uk
> [mailto:snmp-bounces at snmp.westhawk.co.uk] On Behalf Of Birgit Arkesteijn
> Sent: Wednesday, October 31, 2007 8:15 PM
> To: List for discussion of the Westhawk SNMP stack
> Cc: Nookala, Sridevi (Sridevi)
> Subject: Re: [snmp] Need way to re-discover timeline info to recover
> fromusmStatsNotInTimeWindows
> 
> Hi Sharath,
> 
> We added:
> public void TimeWindow.clearTimeWindow(java.lang.String snmpEngineId)
> 
> but haven't (yet) turned that change into a public release.
> 
> You can download the code, however, from SourceForge.
> http://sourceforge.net/projects/westhawksnmp/
> 
> I don't think keeping the SNMPv3 discovery details when a context is 
> destroyed is wasteful. It saves (potential) two discovery PDUs when a 
> new context is created and a new request PDU sent. We're not talking 
> about bulk data either, so it won't take up that much space.
> 
> Cheers, Birgit
> 
> 
> On 31/10/07 12:18, K, Sharath (Sharath) wrote:
>> Hello,
>> We are using the westhawk stack version 5.0 in one of our management
>> applications, which connect to SNMPv3 based network elements (NEs).
>>
>> We create the NE on the manager application and use the stack to
>> heartbeat (GET a couple of SNMP scalar attributes) the NE every 1
>> minute.
>> Once the NE is created on the manager, a new SnmpContext is also
> created
>> and cached till the NE is deleted from the application. Upon deleting
>> the NE, the context is also destroyed.
>> We are facing a situation where-in the engineId, engineBoots and
>> engineTime are in synch between the manager and the NE (authoritative
>> engine), up until some commands are executed on the NE which update
> the
>> snmp configuration. When these commands are executed on the NE, the
>> engineTime is being reset to 0 on the NE, but the engineBoots remains
>> the same.
>> When the manager now sends out the next heartbeat SNMP GET request, we
>> get a usmStatsNotInTimeWindows error since the local engineTime is
>> greater than the NE's engineTime.
>> The only way to recover from this situation is to restart the manager
>> application (and hence the stack), which we cannot afford to do. I
>> initially thought that once the context corresponding to the NE was
>> destroyed and re-created, it would re-discover by sending
> engineBoots=0
>> and engineTime=0, but the stack still retains the old values of
>> engineBoots and engineTime even if there is no corresponding context.
>>
>> I tried to do a forced discovery whenever usmStatsNotInTimeWindows
>> exception was detected, but this does not update the timeline info.
>> I see from TimeWindow.updateTimeWindow(), that timeline is updated
> only
>> 	if (bootsA > bootsL ||
>>                (bootsA == bootsL && timeA > latestL))
>>
>> But in our case, bootsA == bootsL, but timeA < latestL.
>>
>> Is there a way to recover from this situation?
>>
>> Can you provide some public methods in TimeWindow.java to clear the
>> engineId and/or engineBoots and engineTime entries from the
> "hostLookup"
>> and "engineLookup" Hashtables?
>> This will enable us to re-initate a discovery and recover from this
>> situation.
>>
>> Or
>>
>> How about removing the corresponding entries in the hostLookup and
>> engineLookup Hashtables upon a context getting destroyed?
>> Because once the entries are stored for a given ip:port combination,
>> they remain for the lifetime of the stack, even if there is no context
>> associated with the given ip and port. Doesn't this seem wasteful?
>>
>> Any other suggestions to overcome this situation will be helpful.
>>
>> Thanks,
>> Sharath
>>
>> _______________________________________________
>> snmp mailing list
>> snmp at snmp.westhawk.co.uk
>> http://snmp.westhawk.co.uk/mailman/listinfo/snmp
> 

-- 
-- Birgit Arkesteijn, birgit at westhawk.co.uk,
-- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK
-- Company no: 1769350
-- Registered Office:
-- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK.
-- tel.: +44 (0)161 237 0660
-- <URL: http://www.westhawk.co.uk>