Operational Defect Database
BugZero updated this defect 58 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
VMware | 362758
Smarts IP: Discovery timeout error; 'SNMP-ETIMEOUT-Timed out' seen in Smarts IP log
Last update date:
3/22/2024
Affected products:
Smart Assurance - SMARTS
Affected releases:
No affected releases provided.
Fixed releases:
No fixed releases provided.
Description:
Symptoms
Smarts IP Discovery timeout errorSmarts IP log file displays the following error message: [14-Jul-2008 04:50:42 PM+089ms BST] t@60 Discovery #4SWFE-W-ETIMEOUT-GET_NEXT request timed out for Agent : x.x.x.x, OID: .1.3.6.1.2.1.2.2.1.3.10115SNMP-ERESPONSE-No response from x.x.x.x, port 161SNMP-ETIMEOUT-Timed out The snoop output shows a trap generated by the device's agent as a response to the get-next-request as in the following example: get-next-request Simple Network Management Protocol version: version-1 (0) community: ABC@2 trap Simple Network Management Protocol version: version-1 (0) community: ABC data: trap (4) trap enterprise: 1.3.6.1.4.1.9.1.217 (SNMPv2-SMI::enterprises.9.1.217) agent-addr: x.x.x.x (x.x.x.x) generic-trap: authenticationFailure (4)Another Example for SNMP Timeout issue: Basically when a walk request is sent to the device SNMP agent process, the expectation is to get a response with the data or respond with "NoSuchInstance" and timing out is not a valid response:The OID that the device was timing out was as follows:pimInterfaceStatusOID{".1.3.6.1.3.61.1.1.2.1.7."}This is a multicast discovery OID and used to populate the "MCAST_TopologyCollection" class as part of the end device probe. After loading the MIB walk file in EMC lab machine; performed a manual SNMP walk on the above OID - .1.3.6.1.3.61.1.1.2.1.7 and below is the response: $ ./sm_snmp.exe -c public -s 2c -d <Device IP> -p <Domain Port> walk .1.3.6.1.3.61.1.1.2.1.7SNMP Walk MIB starting at .1.3.6.1.3.61.1.1.2.1.7.1.3.6.1.3.61.1.1.2.1.7.110 = 1.1.3.6.1.3.61.1.1.2.1.7.111 = 1With respect to the above output; there is an output and a valid response. Even "NoSuchInstance" response is considered a valid response.Same command has been executed in user environment against the device <"Problamatic Device"> and observe the below output. [root@xxxx bin]# ./sm_snmp -c <community_string> -s 2c -d <Device IP> -p <Domain Port> walk .1.3.6.1.3.61.1.1.2.1.7SNMP Walk MIB starting at .1.3.6.1.3.61.1.1.2.1.7[July 11, 2016 2:47:07 PM GMT+01:00 +898ms] t@2097300336 <Primary Thread>SNMP-E-ERESPONSE-No response from 169.35.198.221, port 51309SNMP-ETIMEOUT-Timed out; in file "/work/tancurrent/DMT-9.2.0.0/19/smarts/snmp/lib/SNMP_RequestsSender.c" at line 1337With respect to the above output; its timing out.
Cause
The SNMP-TIMEOUT is happening for the VLAN walks. The VLAN walk walks the dot1dBridge (OID ".1.3.6.1.2.1.17") appending the VLAN ID to the original community string. For each of the getnext requests with community string "ABC@2" (this is the walk for VLAN ID 2) the agent sends an authenticationFailure trap. Since there is no response for these requests, the time out occurs.
Resolution
Smarts is working as designed. This issue indicates a problem with the SNMP agent and must be addressed with the SNMP agent vendor.
