Determine duplicate SNMP Engine IDs and their impacts
search cancel

Determine duplicate SNMP Engine IDs and their impacts

book

Article ID: 331245

calendar_today

Updated On: 03-11-2025

Products

VMware Smart Assurance VMware Telco Cloud Service Assurance

Issue/Introduction

Every device is meant to have a unique Engine ID and if this is not the case, it can cause all kinds of problems, for instance pull config of the device will fail.
Duplicate SNMP Engine IDs can cause pull config and discovery to fail

Some customers need to be able to obtain the device SNMP Engine ID in order to determine if they have any devices with duplicate Engine IDs on their system.

Devices with duplicate Engine IDs are non-complaint with RFC 3411 (Ref: https://www.ietf.org/rfc/rfc3411.txt)
According to the RFC no network device can have the same SNMP V3 engine ID.



Environment

NCM 10.x

Resolution

There is no mechanism in NCM to see or retrieve all the list of engineIDs. Whenever you do pull or discovery you can see that particular engineID of the device in NCM autodisc logs and commmgr logs. However, here you will see only one engineID this will not help you to identify duplicate engineIDs.

There are 2 workarounds: 

Using NCM to find the Engine IDs

The following can be set up via the NCM Gui :
Please note: these steps to be run favorably on v3 devices. Other devices can throw invalid command 

  • select the devices in NCM GUI.
  • Rightclick->Editor->Command->terminalComand
  • Enter the device specific command to get the SNMP Engine ID for v3 devices e.g. for some Cisco devices, this command is "show snmp engineid"
  • schedule in Tasks select do not pull
  • run on approve.  
 
You will see the following in the commmgr.log:
 
Jun 17 12:25:49 -311477360/push(100169)#4: show snmp engineid
Jun 17 12:25:49 -311477360/push(100169)#4: Local SNMP engineID: 8000000XXXXXXXXXXXX
Jun 17 12:25:49 -311477360/push(100169)#4: Remote Engine ID          IP-addr    Port
Jun 17 12:25:49 -311477360/push(100169)#4: Switch167#

This can be scheduled as a job to run on all devices as per user requirements. 

 
Not using Smarts 
  • Proactively find these devices with the help of your local network admins .
  • Discover them in different networks or different device servers.