Smarts IP: Discovery Errors when ContextMapping and ContextName are different
Article ID: 332205
Updated On:
Products
Issue/Introduction
When performing a discovery and the discovery for the device failed with the following message:
[07-Nov-2017 01:43:42 PM EST +253ms] t@920540928 Discovery #26
ASL_MSG-*-ASLP-discovery/ic-cisco-find-context.asl: discovery/ic-cisco-find-context.asl: Start driver to get:management context data
[07-Nov-2017 01:44:03 PM EST +276ms] t@920540928 Discovery #26
SNMP-E-AGENTERRORSTATS-Below message for SNMP agent at 'aaa.bbb.ccc.ddd:xxx', was suppressed 1 times since 05-Nov-2017 09:47:40 AM EST
SWFE-ETIMEOUT-GET_NEXT request timed out for Agent : aaa.bbb.ccc.ddd, OID: .1.3.6.1.2.1.4.20.1.2
SNMP-ERESPONSE-No response from aaa.bbb.ccc.ddd, port xxx
SNMP-ETIMEOUT-Timed out; in file "/work/redcurrent/DMT-9.4.2.0/10/smarts/snmp/lib/SNMP_RequestsSender.c" at line 1337
[07-Nov-2017 01:44:03 PM EST +277ms] t@920540928 Discovery #26
ASL_MSG-*-ASLP-discovery/ic-cisco-context-data.asl: discovery/ic-cisco-context-data.aslCurrent Context Name: <context name>
Tcp ping would time out. If as in this situation there is no data, then SNMP agent should return NoSuchInstance reply instead of simply timing out which is not a valid response and hence the discovery error.
Environment
Cause
Customer have configured a vrf "<vrf name>" with the context "<context name>" and these information are populated via the below oids.
{10, ".1.3.6.1.6.3.18.1.1.1.5"} #snmpCommunityContextName{20, ".1.3.6.1.4.1.9.9.468.1.1.1.2"} #ciscoContextMapping
The reason to include and read the ciscoContextMappingOID (i.e .1.3.6.1.4.1.9.9.468.1.1.1.2) is because of implementing a strategy on managing a Cisco Nexus switch with multiple VRFs using SNMPv3.
Previously with SNMPv2, one can use the VDC contexts to map to each VRF. This would populate the SNMP-COMMUNITY-MIB::snmpCommunityContextName (.1.3.6.1.6.3.18.1.1.1.5) OID. Smarts would query this OID when discovering the device and then use the <community>@<context> syntax to discover and aggregate the results. However, when the VDC/VRF mapping is removed (a Cisco SNMPv2 command), the SNMP-COMMUNITY-MIB::snmpCommunityContextName OID is no longer populated. This results in only the default VRF being discovered.
An option to achieve this is to map a SNMPv3 security context to a VRF. This means that Smarts would have to be modified to discover all the security context on the Nexus switch. As per recommnedation from Cisco, we can use "CISCO-CONTEXT-MAPPING-MIB" to discover the context which should populated for both SNMPv2c and SNMPv3.
To do this, Smarts discovery included a logic to walk both the "snmpCommunityContextName" and "ciscoContextMapping" and add all the context information to a tables and use it to walk the context for information.
The problem is, if there are overlapping details, the information would get overridden in the table and thus retaining only unique entries. Thus a code change was made so when the context and VRF name are different, Smarts would seem them as two different context and hence the issue with discovery in this case.
Resolution
Feedback
