Smarts IP: Discovery errors when attempting to poll ipAdEntIfIndex; Errors: SWFE-E-EGETNEXT-While getting next of OID .1.3.6.1.2.1.4.20.1.2; SNMP-ETIMEOUT-Timed out; SNMP-ERESPONSE-No response from <IP_address>

Products

• VMware Smart Assurance

Issue/Introduction

Symptoms:

Discovery of device is failing with the following errors:

SWFE-E-EGETNEXT-While getting next of OID .1.3.6.1.2.1.4.20.1.2,
SNMP-ERESPONSE-No response from <IP address>, port 161
SNMP-ETIMEOUT-Timed out; in file "/work/tancurrent/DMT-9.2.0.0/19/smarts/snmp/lib/SNMP_RequestsSender.c" at line 1337

 

The below timeout error is observed when attempting to discover device:

SWFE-E-EGETNEXT-While getting next of OID .1.3.6.1.2.1.4.20.1.2,
SNMP-ERESPONSE-No response from <IP address>, port 161
SNMP-ETIMEOUT-Timed out; in file "/work/tancurrent/DMT-9.2.0.0/19/smarts/snmp/lib/SNMP_RequestsSender.c" at line 1337

This error occurs when Smarts IP generates an SNMP getBulkRequest against oid 1.3.6.1.2.1.4.20.1.2.

From the Packet Capture, we can see that that the getBulkRequest uses an incorrect SNMP community string.
The incorrect string used was a combination snmpCommunityName and snmpCommunityContextName.

Environment

VMware Smart Assurance - SMARTS

Cause

The incorrect string used was a combination snmpCommunityName and snmpCommunityContextName.

An SNMP context is a collection of management information accessible by an SNMP entity.  An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts [RFC3411].  A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName). For more information, please see RFC5343.

We can configure many contexts in a device and associate private IP addresses to each context. 
In this example the device had an snmpCommunityContextName configured for testing purposes.

In this example, we see "{7e" returned as the snmpCommunityContextName from the device :

[root@my-vm bin]#snmpwalk -v2c -c <mycomunitystring> <IP_Address> .1.3.6.1.6.3.18.1.1.1.5

SNMP-COMMUNITY-MIB::snmpCommunityContextName.'.-281681390' = STRING: {7e
SNMP-COMMUNITY-MIB::snmpCommunityContextName.'.-585397208' = STRING:
SNMP-COMMUNITY-MIB::snmpCommunityContextName.'.-693767188' = STRING:
SNMP-COMMUNITY-MIB::snmpCommunityContextName.'.1690985161' = STRING:
SNMP-COMMUNITY-MIB::snmpCommunityContextName.'.-1854548317' = STRING:

Resolution

Smarts IP is working as designed. Smarts IP combines these two strings to discover the private IP addresses on a device:

snmpCommunityName
snmpCommunityContextName

And then polling these OID values:
 
ifIPAddressOID          {".1.3.6.1.2.1.4.20.1.2"}
IfNetmaskOID            {".1.3.6.1.2.1.4.20.1.3"}
 
If the polling of the context based information requires a different community string than the one generated from the combination of base community and context name, the polling will fail.
 
Workaround:
Removing the snmpCommunityContextName from the device in question should allow discovery to complete successfully. The procedure is vendor specific, but should be possible using the GUI or CLI, whichever is used to configure the device.