On 8/4/10 7:28 PM, wing2009 wrote:
I've done that already. AFAICT, the values stated the same which was "0" for
remoteTpPort10 and "1" for remoteFpPort10 all the time.
F.Y.I. I have this one on my<snmp-device-properties> section.
maxvars = "30"
And from the debug log file, this is the entry when the alarm triggered
18:41:05 Device-Name: SNMP error status [[93 query = QUERY_CustomRouter]] genErr (5),
index=16, oid=""
genErr (5) is a "general error" in the SNMP response. The agent at the
other end will report this error when it runs into an unexpected
failure. It usually means that the agent couldn't retrieve the value of
an OID due to a bug. In this case, the 'genErr' is complaining about the
16'th oid, which doesn't appear to exist in the response packet, but
appeared in your request.
It looks like InterMapper continues to process the SNMP response in
spite of the genErr error status. The response packet may contain zero
values, thus triggering your threshold.
You might try setting maxvars to 15 or changing the order of the OID's
in your probe. You want the OID that occasionally elicits the genErr to
never be in the same SNMP request as the critical OID's that trigger
your threshold.
--
Bill Fisher
Dartware, LLC
____________________________________________________________________
List archives:
http://www.mail-archive.com/intermapper-talk%40list.dartware.com/
To unsubscribe: send email to: [email protected]
