Smarts IP: SNMPv2 agent is looping on discovery of host; "Agent loops" discovery error

Products

• VMware

Issue/Introduction

Symptoms:




Smarts IP discovery error on Window Hosts
26-Oct-2009 12:33:43 PM+287ms Pacific Daylight Time] t@2664 Discovery #8
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First
   OID: .1.3.6.1.4.1.232.6.2.9.3.1.3

[26-Oct-2009 12:33:43 PM+303ms Pacific Daylight Time] t@2664 Discovery #8
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First
   OID: .1.3.6.1.4.1.232.6.2.6.7.1.2

[26-Oct-2009 12:33:43 PM+319ms Pacific Daylight Time] t@2664 Discovery #8
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First
   OID: .1.3.6.1.4.1.232.6.2.6.8.1.2

[26-Oct-2009 12:33:43 PM+319ms Pacific Daylight Time] t@2664 Discovery #8
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First
   OID: .1.3.6.1.4.1.2021.4.3

[26-Oct-2009 12:33:43 PM+319ms Pacific Daylight Time] t@2664 Discovery #8
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.1.1.1, First
   OID: .1.3.6.1.4.1.2021.4.5

SNMPv2 agent is looping on Smarts IP discovery of SystemEdge host

The following "Agent loops" discovery error for OID .1.3.6.1.4.1.674.10892.1.400.20.1.7 appears in Smarts discovery progress window and in Smarts IP server log: 

[16-Sep-2009 15:36:09+246ms SAST] t@56 Discovery #1
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.204.20.70, First
   OID: .1.3.6.1.4.1.674.10892.1.400.20.1.5

[16-Sep-2009 15:36:09+251ms SAST] t@56 Discovery #1
SWFE-W-ELOOP-Agent loops in response to GET_NEXT: Agent: 10.204.20.70, First
   OID: .1.3.6.1.4.1.674.10892.1.400.20.1.7

Response from a GET_BULK of the OID .1.3.6.1.4.1.674.10892.1.400.20.1.7 returns a NoSuchName / NoSuchInstance exception in packet trace from a Smarts IP discovery of the device

Environment

VMware Smart Assurance - SMARTS

Cause

The SNMPv2 bulk request of OID .1.3.6.1.4.1.674.10892.1.400.20.1.7 returns a noSuchInstance error and returns the same polled OID in response. This is incorrect according to RFC definitions, so the SNMPAgent implementation for SNMPV2c version is incorrect for these devices.

According to latest the RFC 3416 (http://tools.ietf.org/html/rfc3416), for Bulk/getNext requests of an OID (out of MIB tree range, no lexicographic successor), an SNMP Agent should give an EndofMibview value and no error for error status. The following explanation of this behavior is found in RFC 3416 and RFC 1905:

" (2) If the requested variable bindings name does not lexicographically precede the name of any variable
accessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding produced
in the Response-PDU has its value field set to "endOfMibView", and its name field set to the variable bindings name in the request."

Resolution

This is an SNMPv2 agent issue that must be addressed with the agent vendor to resolve. To work around this issue, you can discover the device through SNMPv1.