Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Smarts NCM/VoyenceControl: How is a device identified and determined to be unique? (305114)

Last Updated: 3/22/2024Categories: How toTotal Views: 2412Language:
English

1 like this article

Subscribe to get an email
newsletter with new updates

1 people found this helpful Please provide article feedback:

Resolution

How is a device identified in by Smarts NCM/VoyenceControl?
How does by Smarts NCM/VoyenceControl determine device uniqueness?

NCM "Two out of Three" Rule

Voyence Control / 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:

IP Address

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 EMCÂ® SmartsÂ® Network Configuration Manager 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.

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.

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. VoyenceControl 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 push out 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.

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
English

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

Related Versions:

VMware Smart Assurance - NCM

Take Our Survey

Support Assistant