How Does Discovery Correlation Work?

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

It's important to understand that discovery correlation happens in an order of priority and when a correlation is made, we stop trying to correlate on weaker correlation methods.

Environment

Release: 8.x, 9.x

Resolution

In order of priority, the types are as follows

Device UUID
VM ID
Robot device ID
MAC address
Fully qualified domain name (FQDN)
Simple name + origin
IP address + origin

Method Descriptions

Strong Correlators

Device UUID corresponds to the cs_key that is found in the CM_DEVICE_ATTRIBUTE table. You'll rarely encounter this attribute, however, it can be used for the cm_data_import probe when defining an XML import template.

VM ID is a reference to a unique ID that is assigned to a virtual machine. This ID is useful for tracking VMs as they might vMotion from one host to another or if IPs change. Discovery_agent is also able to detect this value.

Robot device ID is the hash value of the robot which can be found in the niscache folder. This is a generated value based on IP address + robot name. If either of these values changes (even case change from uppercase to lowercase), a new robot ID is created.

MAC address is the "unique" value that is assigned to each network card. In some cases, this value is not actually unique, particularly in the case of virtual machines. Because of this, we exclude certain vendors' MAC addresses from correlating so that distinct VMs do not begin to correlate as a single device. MAC addresses can be determined the number of ways, but one way that discovery_agent determines them is to check it's ARP cache. If the discovery_agent exists on the same subnet as the device it is scanning, it will be able to find this information.

Fully qualified domain names are the last strong correlator. FQDN can be found via reverse DNS lookups, some probes will present FQDN depending on how they are configured and other times it is found via information we know about the system. For example, the VMWare probe will report the FQDN if the VM has VM Tools installed on it.

Weak Correlators

Methods 6 and 7 are considered "weak correlators". We frequently see correlation problems with these types of correlation due to information coming from separate hubs which are presenting different origins, for example. discovery_server simply does not have much information to go on in these situations, and it is encouraged to make as much information available to discovery methods as possible.

An example of this is where we have used discovery_agent from HUB1 to discover a router and we are using net_connect from HUB2 to verify availability. Each of these will show up as two different devices in USM because all we know about the device is an IP address, but the origins of the QOS_MESSAGEs will be HUB1 and HUB2.

Flowchart