Troubleshooting
Problem
After successfully configuring the agent to use SNMPv1 to monitor remote AIX nodes, no data is received in Tivoli Enterprise Portal Server (TEPS). An snmpwalk can successfully be performed against the remote host, yet no data is received in TEPS.
Symptom
At ERROR level tracing, in the agent RAS1 log you see a lot of the following Timeout messages indicating no response was received from the remote system:
(51F6C0B0.0014-3D:snmpqueryclass.cpp,2066,"internalCollectData") Timeout occurred. No response from system1.company.com.
(51F6C0B0.0015-18:snmpqueryclass.cpp,1389,"handle_snmp_response_async") ERROR: decoded PDU is null -- this is a timeout scenario
When tracing is set to (UNIT:SNMP ALL), the RAS1 log for the agent will show a wrong community name being used: In the example below, it shows a community name of "public", however the instance was configured to use a different community name:
(52011E94.00A2-C:snmphelp.c,923,"dumpPDU") ==================Begin PDU Dump Info ==================
+52011E94.00A2 PDU Length: 140
+52011E94.00A2
+52011E94.00A2 30 81 89 02 01 00 04 06 70 75 62 6c 69 63 a1 7c
0....... public.|
Cause
There were two configurations performed one for SNMP V2 using one community and a second time for SNMP V1 using a different community name:
1) SNMP v2 was used earlier with the "public" community name.
2) SNMP v1 was used later with a different community name but this was never being used.
Environment
Operating System: AIX 5.3 (5300-12-05-1140). Agent version: 6.23
This can also occur across Agentless agent releases and across versions.
Diagnosing The Problem
Check the remote agent configuration file. <hostname>_r3_<instance_name>.cfg
Two community names were present as follows:
SECTION=KQZ_SNMPV1 [ {
SNMP_COMMUNITY=\{AES256:keyfile:a\}y9xY+jPpmAxQUQlO8Bn4cA\=\= } ]
SECTION=KQZ_SNMPV2 [ {
SNMP_COMMUNITY=\{AES256:keyfile:a\}Ug0mS8MIJtuNNo6dsy4f6Q\=\= } ]
Since the agent was configured twice the previous community name was being considered.
NOTE: This can occur for any of the Agentless monitoring agents.
Resolving The Problem
Rename/Delete the old <hostname>_r3_<instance_name>.cfg file.
Reconfigure the R3 agent once again, the file will be regenerated after the configuration and the issue will be resolved.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21646331