Quantcast
Channel: THWACK: Message List
Viewing all articles
Browse latest Browse all 20403

Re: Network Sonar Discovery for Large Network

$
0
0

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.


Viewing all articles
Browse latest Browse all 20403

Trending Articles