Scanning Large Ranges with Discovery

[saadit]

Is there any guidance on the maximum number of IP's to scan per schedule? In the past, the rule of thumb I was told by ServiceNow was not to scan anything larger than a /20 i.e. /19 and below. Does this still hold?

Before the glide.discovery.max_range_size default value was 100K for the total number of IP's that can be scanned by a Schedule, I've noticed now that the default value is much higher and the London documentation does not even make reference to the property anymore. Wondering if that's an indication we are OK with scanning large networks now?

I have a client that has all their IPs broken into /16's or /14's and before I go down the path of breaking them into smaller chunks I wanted to get the communities feedback.

Thanks in advance.

[Allen Andreas]

Hi,

If you don't have a very specific range, then I know a lot of people are sticking with /24 or so. That's what we're doing. /16 is too large in my opinion.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Andrew Westerv4]

It's still advisable to create a range set that defines the subnets that are actually in use within the /16 or /14. That way you aren't needlessly over scanning non-existent IP space. It's a performance hit on the Discovery Schedule, but not a deal breaker if this isn't possible.

I believe the Discovery Max Range property was limited because it was necessary for older instances before Shazzam had batch size and clustering support.

[doug_schulze]

Fun fact...Was actually put in because way back in the day we had a good discovery friend get an idea to scan his 'Private IP ranges" range set (20Mil+ IPs) using the localhost mid server we use to deploy with each application node... 🙂 20 mins later when we got all their instances back up, Tom put in the property to say, lets not do that again. So came to the 100k number and after some discussion, we stopped with the Localhost midserver .  But you are right, with batching and clustering its a 'dead' property...

[tim_broberg]

I have seen customers run /16's in production, and it did work, but it was pretty slow. I'm afraid I don't remember how slow.

Eh, I guess you already know - you're running them.

If the performance is acceptable, feel free to leave it.

You're just going to burn mid processing time and network bandwidth scanning wide swaths of empty ports is all.