Device uniqueness during discovery

Products

• VMware Smart Assurance

Issue/Introduction

• How is a device identified and determined to be unique?
• How does Smarts NCM determine device uniqueness and not overwrite.

Environment

NCM - 10.1.x

Resolution

NCM uses "Two out of Three" Rule

Smarts Network Configuration Manager (NCM) applies a "Two out of Three" rule against multiple device metadata property values retrieved from a target device during any discovery attempt to determine if the device is unique, or if it is already known to NCM. This means that NCM must be able to retrieve at least two (2) common metadata values from the device, and that at least two (2) of the retrieved values must be different from the metadata values stored for any other device already known to NCM. The required device property values are:

1. IP Address
2. sysObjectID (Device Model):

The discovery mechanism(s) in effect at the time a target device is discovered can affect this value.

• SNMP: 

SNMP is the highest priority mechanism in determining device model. It is used to query the target device for the value stored in its sysObjectID MIB node (1.3.6.1.2.1.1.2.0). For known devices, this value correlates directly to a specific model name that will be displayed for the device in the NCM Client UI. If the model is not listed as a supported model in the NCM Device Services Support (DSR) Support Matrix document associated with the DSR version deployed in the instance, the model shown in the NCM Client UI will be arbitrarily determined by driver code.

                  NOTE: Support matrix can be downloaded from https://docs.vmware.com/en/VMware-Smart-Assurance/index.html. 

• CLI:

In cases where CLI is used to determine the model of a target device, NCM will attempt to parse the output of various commands issued in a CLI session with the device to isolate the model name or model alias. If successful, the driver will attempt a reverse lookup using the retrieved value to identify the sysObjectID value for the device found in a list of known device models and model aliases. NCM cannot provide a sysObjectID value for an unsupported device without prior customization to the DSr package deployed in the instance if the device discovery uses only the CLI mechanism. 

3. Unique ID (UID):

For the vast majority of devices in NCM, the UID value equates to the device serial number. However, the drivers for some device classes implement the MAC Address, sysName, IP Address (again), or some combination of those values as the UID. NCM is usually limited during discovery to whatever unique metadata values it can successfully retrieve from the device when attempting to determine the UID for the device, although a small minority of drivers may implement a preset default UID.

Various operations performed on a device have the potential to alter any of the above three values. For example:

• The sysObjectID value of a target device may change if a different device Operation System (OS) is loaded onto a device after it has already been discovered in NCM.
• Physical update to a device chassis may result in a change of serial number or other unique metadata value relied upon by the NCM device driver assigned to a target device under management.
• The device may be reconfigured to use a different IP address on the management port known to NCM.

Care must be taken when performing any of these operations to understand the effects they may have on NCM's ability to recognize the device once the operation has been completed. In some cases, the device may need to be discovered again and accepted under NCM management as a previously unknown device with no prior history. For example, if the device operating system was replaced by another operating system that is not part of the same operating system branch from the same manufacturer, it will usually change the sysObjectID returned by the device in response to an SNMP query. Additionally, the new device OS may not be 100% compatible with older configuration files NCM would otherwise make available to perform push to the device. In these cases, the device configuration history will no longer be applicable to the OS residing on the device after an OS change.