Operational Defect Database

BugZero updated this defect 58 days ago.

VMware | 382992

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

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 error on Window Hosts 26-Oct-2009 12:33:43 PM+287ms Pacific Daylight Time] t@2664 Discovery #8SWFE-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 #8SWFE-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 #8SWFE-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 #8SWFE-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 #8SWFE-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 #1SWFE-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 #1SWFE-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

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 variableaccessible by this request, i.e., there is no lexicographic successor, then the corresponding variable binding producedin 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.

Additional Resources / Links

Share:

BugZero® Risk Score

What's this?

Coming soon

Status

Unavailable

Learn More

Search:

...