1 of 1 people found this helpful
Presumably it is succeeding on multiple end points in the scanner. Are you scanning the same device from different endpoints on different scanners? You need to sort that out. There is nothing you can do on the consolidator.
Discovery makes a strong effort to use the active DiscoveryAccess associated with a scan to perform discovery requests. What pattern is making the requests?
We do have another standalone scanner (running 220.127.116.11) also scanning the endpoint but at a different time. What I don't understand is, why is it not skipping discovery on the other IP (.136) as it is does at other times? In this particular example it looks as the IP ending in (.145) is the main IP DiscoveryAccess is always successfully scanning on.
When we do have the condition of DiscoveryAccess scanning multiple IPs with SUCCESS on the same device, I have noticed some differences in the runCommand results on the scanner vs. consolidator.
Here is the result from the scanner for the IP (.145):
Here is the result from the consolidator of the IP (.145):
Here is the result from the scanner for the IP (.136) - appears that it is only performing a partial scan:
Here is the result from the consolidator for the IP (.136) - notice the many "Request for information not part of the consolidation data" errors:
These are the runCommand results from the 20 errors from the consolidator on IP (.136) involving many different patterns:
The consolidator treats data from scanner in choosing the best IP as correct. The fact you are scanning the same things from two different scanners is what is really wrong.
You would find Discovery 11.1 is likely to do a better job as it is more directed to picking the scanning DiscoveryAccess than earlier versions.
Ok - I misunderstood you because you were talking about consolidators.
If you get two IPs for an endpoint at almost exactly the same time and the scan optimisation timeout has passed then both can happen because the new IP takes over being the best IP. There are multiple processes and nothing which locks across the complete system to prevent this.
A Discovery 11.1 or later consolidator should handle this better without lots of not part of consolidate data errors.