SNMP Engine ID as an Identifier for Network Gear

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-28-2017 12:23 PM
I have some network switches that are causing me trouble with the identification phase of Discovery runs. The other ports on the switch often return different results than the management port when the SNMP Identity probes are run. Typically the management port will return the serial and hostname (without domain) while other ports on the same switch often don't return the serial and may return an FQDN instead of hostname without the domain. Since they aren't returning the serial, are using a different IP, and return a different value for the name, the result is a duplicated CI. I have around 600 network gear CIs, and roughly a third of those are duplicates. This seems to be an issue that is mostly limited to Cisco Nexus devices, and is particularly bad with devices like the Nexus 7000 that uses virtualized switches (i.e. VDCs) that run on the physical device.
One of our network engineers has pointed me towards the SNMP Engine ID as a consistent way of identifying discrete devices (whether physical or virtual):
1.3.6.1.6.3.10.2.1.1.0
iso.org.dod.internet.snmpV2.snmpModules.snmpFrameworkMIB.snmpFrameworkMIBObjects.snmpEngine.snmpEngineID
But I haven't done much in the way of customizing Discovery probes/sensors. What I have done was focused on SSH probes running against Linux, while SNMP isn't something that I've got a lot of experience with. So far in my investigation, I'm finding the customization to be pretty complicated and I'm hoping someone out there has done this before or has the experience to help me work this out.
So far I've added an SNMP field to the "SNMP - Identity Info" multiprobe and I'm not sure whether I need a multisensor script or a new probe or to customize an existing probe as my next step:
I'm hoping someone can help me figure out a simple way to do this.
- Labels:
-
Discovery

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-08-2017 06:00 AM
I too have faced this. Even though you can get the information from that OID, a sensor is required to use it successfully. Now the questions is, how do you want these devices to be in CMDB. You will have to modify sensor associated with "SNMP - identity info" to take this value into consideration along with what it is doing already.
Another strategy can be to append the Name with the value from this OID making the Name field unique. And since Name is already being looked at by current identity sensor, you can save on major sensor changes. Also keep in mind that the changes to identity sensor will remove it from future updates list as well.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-21-2018 08:43 AM
Any luck on discovering Nexus 9k switches? I too am seeing the same issues as the OP pointed out with this hanging when the identify phase runs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-05-2018 08:10 AM
Same here but with the Nexus 7k series. To make it worse, Kingston's discovery generates millions of error messages to the log due to complaints about duplicate serial numbers and other fields since discovery returns the same serial number for all VDCs and cards.