Hi Sachin,
We have an article that might help to clear up a few of these questions:
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.
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 change (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 a 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
