Hi,
(Linux 4.19.317 snmp++-3.6.6 / agent++-4.7.2 / agentx++-2.6.1)
I am experiencing the occasional timeout when issuing an snmpset (SNMP v3) - the default is a 1s timeout and 5 retries - nonetheless it will seemingly randomly timeout with no response.
My question is, what kind of scenario could provoke this? We are in an environment where the agent is being accessed from an external host, as well as localhost (localhost usually doing snmpgets, the external host doing a mix of snmpget and snmpset)
If there’s something wrong with the associated subagent (i.e. excessive mib locking), could this result in the overall request timing out? Anything in the logs I should be looking for?
The majority (if not all) timeouts are when issuing snmpset
Happy to provide further information - just don’t want to paste useless stuff in the opening post..
Thanks
Steve
Hi Steven,
The general cause is MIB object locking. For write access (i.e., SET request processing), the MIB objects affected by the SET request need to be exclusively locked and the lock must be hold until all of the variable bindings in the SET request have been committed (or undone or canceled).
If the commit processing of a single or more of those VBs takes longer. A second request touching the same objects have to wait and - if waiting takes longer than the configured timeout - the request will be cancelled/dropped silently.
GET requests might be affected as well, but here the locking takes place on single VB basis. Thus, once a value was read, the lock will be released for that MibLeaf.
Deadlocks can happen too, if requests order VBs in conflicting order. In that case, both requests may timeout.
To improve the situation, clients should send the VB OIDs in the same order (for example lexicographic ascending). In SNMP4J-Agent I have implemented a reordering of VBs for internal processing to avoid such deadlocks within the agent. For version 5.0.0, I will try the same for AGENT++. Until then, the order should be optimised on client level. Even with reordering, this is the best solution for the overall performance.
Hope this helps.
Best regards,
Frank