Network Sonar Discovery for Large Network

Simply put, break it up. If you have a ton of devices, or a ton of devices which are slow to respond (and admittedly, network discovery is the slowest thing SolarWinds does. Once the box is discovered, everything else is pretty snappy), or a ton of devices that are on slow WAN links, or whatever, you are best to break it down into bit-sized chunks. Here's what I recommend:

1. First, I'm going to question whether you really have 16 million systems to monitor. If not, start by scanning the subnet where all your monitor-able nodes are. Everything else is gravy. Scanning all of 10.0.0.0/8 is the definition of "boiling the ocean"
2. Second, like I said, break it down. Start by taking a single "class C" of your network block (10.0.0.0/24) and see how discovery goes. If you can get that done in a reasonable amount of time, extend it to two or three "class C" blocks at a time. Keep expanding that out until you hit whatever limit the poller can handle.
3. Run discovery ON the primary poller. Not on your PC or anything else. The closer you get to the center of the discovery, the better.
4. If you know that machines should be responding quickly, try cutting down the retries and/or the timeouts
5. If you don't want devices which only respond to ping, use that little check-box  that says "don't add devices which only respond to ICMP.
6. Finally, you can also break things down by WMI or SNMP simply by changing the timeout and retry values for each protocol.

If *all* of that still is taking too long, I'd recommend investing in a copy of the Engineer's Toolkit and running discovery there. The toolkit can export nodes directly to the Solarwinds database, so that your poller isn't getting hammered each time you try to discover another part of your network.

I concur. My network is some 12 thousand odd network devices and we do not ever scan anything larger than a /24 at a time - mostly because there are so many individual things to monitor and customize after that. I think it gets too cumbersome in the long run.

I think you've illustrated why Network Sonar discovery doesn't work on large networks, but I've given up flogging that dead horse.

We have about 15,000 network devices and we don't (didn't run discovery). when we install something our Change process has someone add it to our CMDB and we populate Solarwinds.

UDT requires discovery, and it's broken.

Honestly I can't understate the value of a good CMDB: I have been through many audits and I really like being able to pull a report and give it to the auditors in a few minutes (seriously, I just did this for another audit 20 minutes ago). When the financial auditors start to look at the asset database they can then find the equipment in your CMDB, and then see it monitored on the network and go away all sad-faced because there's nothing to 'find'

<IM(ns)HO>

- - - - - clip and save! - - - - - - -

Discovery is an amazingly useful technique. But it is NOT a useful technique for the realm of Monitoring and Automation. But that's a mistake LOTS of people make.

My experience is that onboarding works best when you treat it like a paid service. The only things that get monitored are the things the customer pays for. That goes for devices, elements, applications, etc.

Yes, that requires teams to pro-actively TELL you about a new device, or a drive they've added, or whatever. But you avoid the whole "can't you just discover (rediscover, auto-update) everything" conundrum that ends up burying many a monitoring installation.

Now "TELLING" you can come in many forms - a report that shows new records in the CMDB is one way. Copying the monitoring team on new build requests. Giving permission to members of other teams to add new devices, and then creating a report when devices come online but are missing key custom fields. There are ways to manage this workflow.

And what you end up with is the list of monitored systems you WANT, without a bunch of things that nobody cares about.

Off the side, you can have your laptop running Solarwinds Engineer's Toolkit doing mass discoveries, and then programatically comparing that discovery to the things in the SolarWinds db. But that's audit and discovery, NOT monitoring.

- - - - - clip and save! - - - - - - -

</SOAPBOX>

Thank you all for your input. I ended up scanning specific subnets at a time, and the tip of separating SNMP and WMI scans helped greatly.

Hi Leon

Is the Possible in NSD to skip the nodes which does not respond to ICMP

i heard if a device does not respond to ICMP it will check SNMP again and add it even if ICMP fails to respond and shows the device as down

what i want to know is if it does not get any response for ICMP it should move ahead instead of trying SNMP on that device to save the time.

Yes, that is an option now in the discovery settings: