On 7/18/2022 at 9:15 AM, Stuart Weenig said:Oddly enough, I don't think I've run into an issue where LM doesn't deduplicate, except in the case of multiple VRFs on a single device, in which case you actually don't want to deduplicate. I'm not actually sure the exact logic to determine a duplicate though.
I'm familiar with "preferred monitoring interface" rules that exist in other products and LM has no such capability today that I'm aware of.
I'm assuming you put an IP range in your Netscan and that ip range included the loopback IPs as well as the VLAN IPs?
And you can't just exclude the VLAN IPs because that would also exclude the majority of the servers in your datacenter that you want to monitor, right?
At the time of the netscan run, are there monitoring credentials available to the netscan so that it can access things like sysname and sysoid during the netscan, not after? If, during the netscan, the collector can't access the device, it won't be able to compare things like sysname and sysuptime to determine duplicates. If it can't determine duplicates, it just spits out the entire list of every IP that responds.
Hey Stuart,
I am working off of methods used in previous monitoring solutions I have worked with being new to LM. Typically I would use a dump of my routing tables at my DC Core which would have all of the specific IN-USE subnets in our network 10.0.0.0/8 to make the scan smaller yet very complete. We do have a number of device types that use DHCP as well (AP's and Controller interfaces for SD-WAN Appliances) which will move when they are rebooted. In past experience I have seen little issue as if the scan runs regularly it finds the devices and reconciles via something more immutable like the device serial number. This also helps when a device such as a core switch is scanned that has 10's of IP's assigned.
I have restructured my scans a bit to include specific workable credentials for each scan to give LM a running start. That has helps a bit for sure.
