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

[Birgit Arkesteijn]

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>