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 | 372699
Smarts IP: SNMP v3 IP discovery fails using both seedfile and the Smarts IP GUI, but SNMP v3 sm_snmpwalk using same credentials is successful
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
SNMP v3 IP discovery fails using both seedfile and the Smarts IP GUI, but SNMP v3 sm_snmpwalk using same credentials is successful Device added to Smarts IP pending list with the following message:No response from SNMP agent, V3, agent SNMP-E-EAGENTUSMUSER-AgentREPORT [USM]: Unknown User Name 'decuser' Following messages seen in Smarts IP log file:ADTM-N-AD_LOG-23-Jun-2009 10:37:16 AM, at 'Callback, bad response', while discovering '192.168.111.5', . SNMPError = SNMP-E-ERESPONSE-No response from 192.168.111.5, port 161 . SNMP-ETIMEOUT-Timed out
Cause
Multiple SNMP agents are running the same EngineID. If more than one device is using the same EngineID, there will be collisions in the LCD (Local Configuration Datastore) table and will get the "Unknown User" messages described above. This scenario is unsupported because of the way the RFCs define how the LCD is to be indexed (by engine id and user id). This tuple is the unique key pair into the credentials table where passwords are stored. This is important when either authentication or privacy are used for the v3 devices. In essence, you are "spoofing" one agent with another but duplicating its engine ID and credentials. The engine IDs need to be unique as they are used as part of the encryption key. Once this uniqueness is broken, you cannot guarantee that an authenticated packet came from where it claims to have come from.
Resolution
To resolve this issue, do the following:Check and ensure that there are no SNMP agents running the same EngineID. You can use packet traces and the output of the folowing commands to determine this:sh snmp engineIDsh snmp userFor example, two switches set up with exact same SNMP engineID and user would have output similar to the following:switch2960-165#sh snmp engineIDLocal SNMP engineID: 800000090300001DE5FDFA01Remote Engine ID IP-addr Portswitch2960-165#sh snmp userUser name: decuserEngine ID: 800000090300001DE5FDFA01storage-type: nonvolatile activeAuthentication Protocol: MD5Group-name: dec-groupReset the engineID and user. To resolve this issue using the preceding engineID/user example, the following commands would be used:switch2960-165(config)#no snmp-server user decuser dec-group v3 auth md5 changemeswitch2960-165(config)#no snmp-server group dec-group v3 authswitch2960-165(config)#snmp-server engineID local 800000090300001DE5511E81switch2960-165(config)#snmp-server group dec-group v3 authswitch2960-165(config)#snmp-server user decuser dec-group v3 auth md5 changemeIMPORTANT! Be sure to reset both the engineID and user. Resetting just the engine ID will result in incorrect engineId/user bindings. Once the engineID and user have been reset, the SNMP v3 IP discovery should succeed.
