search NetworkDevice show name, type, vendor, model, #InferredElement:Inference:Associate:DiscoveryAccess.endpoint as 'Scanned via', #InferredElement:Inference:Associate:DiscoveryAccess.end_state as 'End State', #InferredElement:Inference:Associate:DiscoveryAccess.#DiscoveryAccess:DiscoveryAccessResult:DiscoveryResult:DeviceInfo.snmpv3_engine_id as 'SNMP v3 Engine Identifier'

If two NetworkDevices have the same snmpv3_engine_id, the problem is confirmed.  Otherwise, restart the appliance, rescan the network,  then re-execute the query above. This is needed because NetworkDevice nodes are only created after a successful scan (which is not possible until the appliance is restarted in this case).

This query will only show the snmpv3_engine_id that Discovery was able to find. If workaround #1 below (service restart) was not used, the issue may occur even if the query above does not return anything wrong.

- If the following command is executed from the appliance:

sudo tcpdump -i any -s0 host <ipAddress> -w /tmp/snmp_issue.cap

The dump may show the elements below. This is not enough to confirm the cause but it is compatible with it.

- Discovery send get-request
- Device send report 1.3.6.1.6.3.15.1.1.4.0 (    usmStatsUnknownEngineIDs)
- Discovery send get-request with EngineID
- Device send report 1.3.6.1.6.3.15.1.1.5.0 (usmStatsWrongDigests)

Workaround 1:
1A- Restart the Discovery services of a standalone appliance (or the Discovery services of all members of a cluster) before scanning any of the devices that are using a duplicate engine id. Each restart will allow Discovery to scan a single one of the N devices with duplicate engineIDs. If the services are restarted once or twice a day, it could allow Discovery to scan the devices affected by this issue with a reasonable probability of success.
1B- Rescan with SNMP v2.

Note that workaround 3B below (root cause 3, SNMP_USE_ENGINE_ID_CACHE) will not help if root cause 1 is confirmed.

Solution 1A: Upgrade to Discovery 12.0 which contains a fix for defect DRUD1-25505. This fix allows the scans and credential tests to succeed even when the SNMP engine ids are duplicated.
Solution 1B: Change the SNMP v3 engineID of the scanned device and make it unique. This is recommended for security reasons.
For Cisco Devices, it is possible to make it unique using MAC addresses:  see https://supportforums.cisco.com/discussion/11539996/snmp-engineid-same-multiple-routers.
It may be possible to execute a similar procedure for other vendors, such as HP.
Note this solution is not suitable when pairs of master/standby devices share the same engineid (see root cause 2 below).


Root cause 2: Some devices (such as Cisco firewalls, Brocade load balancers, or Juniper devices) can be configured with an Active/Backup setup (also referred to as master/standby). This means that the active and backup devices are two different physical devices but they share internal configurations to support failover.  As they share configurations, they also share SNMP v3 engineIDs.  It is an SNMP v3 security standard that SNMP v3 engine IDs should be unique per device.
Solution 2: Upgrade to Discovery 12.0 which contains a fix for defect DRUD1-25505.
Workaround 2: Use the workarounds provided for root cause 1. 


Root cause 3:  A new network device was found, then replaced (on the same IP, i.e. was installed with a new MAC address and SNMP v3 EngineID), and rescanned. 
Workaround 3:  See workarounds 1A and 1B above
Solution 3A: Upgrade to Discovery 12.0 which contains a fix for defect DRUD1-25505.
Solution 3B: If not already done, upgrade to Discovery version 11.2 or 11.1.0.5 and execute the command below:
tw_options SNMP_USE_ENGINE_ID_CACHE=False
​(enter system password)
Please note that this solution could have an impact on appliance performance in theory.