New Feature: Chunky Pings...

[SlightlyLoony]

Some enterprises have their networks divided into broad, sparsely-populated IP ranges. One enterprise we know uses a /18 (like 10.21.0.0/18) network for each of their locations, large or small. A /18 network has 16,382 possible IP addresses — but there may be only 100 devices actually in that range at a small location.

Now that's no problem for Discovery today. You can create such a range, and Discovery will happily go off and explore it. The challenge lies in how long the initial ping operation takes: at 2 seconds per ping, that's over 9 hours of pinging — and today, nothing else happens until that initial pinging is complete.

So it would be over 9 hours before the rest of the discovery work could even start. When the pinging completes, exploration of all the devices responding to ping starts simultaneously. When you look at your discovery's activities, it looks like nothing happened during the 9 hours of pinging, and then suddenly all sorts of activity breaks out.

Admittedly the example above is an extreme one. But the same effect applies even to much smaller ranges. For instance, a /24 network (probably the most common subnet size) has 252 possible IP addresses — so it takes ping around 8 minutes to check them all.

Here's where our new "chunky ping" feature can help you out. We've created a new property (Discovery Definition → Properties) where you can specify the maximum number of pings to be executed in a single "chunk". If you specify any discovery IP range larger than this property's setting, that range will automatically get split into smaller chunks of work for ping to do.

Here's an example of how the chunky ping logic works. Suppose you've got a Discovery schedule with a /24 network in an IP range — say, 10.10.11.0/24. If your chunk size property is set to 50 (the default), then this range of 252 IP addresses will be split into 6 chunks of 42 IP addresses each. The screenshot at right shows what this looks like in the ECC queue as the ping probes are launched.

With just 42 IP addresses, each chunk finishes in a little over a minute — and then other Discovery activity starts on all the IP addresses that responded. Meanwhile, another chunk is being pinged at the same time. The result: even with large ranges, the Discovery activity starts earlier, and more things are done in parallel. Goodness all around.

There isn't anything magic about the default value we've chosen — it's just one that worked well for us in our testing. If you're the Discovery administrator in your enterprise, you might want to play around with this value a bit to get the results you like the best. I suggest changing it by small amounts and testing; the effects get fairly dramatic as the chunk size gets below about 15...