Does Discovery ping a node initially?

Stuart Spreadbo
Giga Contributor

New to Discovery and untrained, so I apologize in advance for a simple question.

Does the Discovery engine, for a scheduled IP range, initially ping each node before trying to probe that node's ports? i.e. for a 24 bit masked network, 254 ping requests are transmitted and those that get a response will trigger port probes.

Or does Discovery probe the ports of all 254 nodes?

Thanks.

1 ACCEPTED SOLUTION

You are correct, and fly it does, takes milliseconds per IP to make this determination and you have a lot of control over timeouts across the probe, so it's quite handy.  Let's jump in the way back machine and look at a post from the developer that wrote the shazzam probe, our port scanner that does the good work in the first phase of discovery. Take special note to the change that is happening here.  Discovery (10+) years ago did actually Ping (NOT ANYMORE) but we found that alot of environments had ICMP shut off and being wholly dependant on that first (ping) step would prevent us from going forward. So we thought, hey why not just skip to a port check, if its successful we obviously have connectivity and we can learn how to come back to communicate (protocol) with it further down the road.

So his post is about the big switch to how we do it today.

View solution in original post

5 REPLIES 5

doug_schulze
ServiceNow Employee
ServiceNow Employee

Welcome to discovery! This is a good doc to get you started but to directly answer your question.  No we do not ping, we actually do port checks on the most common protocols WMI, SSH, SNMP... ect to identify if an IP is a candidate to be further queried...

Stuart Spreadbo
Giga Contributor

Thanks Doug, appreciated. Both the direct answer and doc link.

The reason I ask is that although the documentation is very detailed and thorough, I could not confirm this for sure. Although it's relatively a very small wait, if the service was waiting for a ping timeout for every unused or unreachable node, it would be delayed when scanning incorrectly enabled or poorly used subnets. If the administrators had mistyped a subnet mask, potentially Discovery is spending a large amount of (relative) time waiting for nodes that will never respond.

To confirm, for every node in the IP range, a connection attempt is made to a selection of initial ports and what happens next is determined by the results, there is no initial 'is the node reachable' stage? The ability to reach the node AND it's port availability are done in the single initial probe? Therefore if the node ports are set appropriately, the nodes are reachable from the MID server, and the MID server properly specified for the processing needs, Discovery flies?

You are correct, and fly it does, takes milliseconds per IP to make this determination and you have a lot of control over timeouts across the probe, so it's quite handy.  Let's jump in the way back machine and look at a post from the developer that wrote the shazzam probe, our port scanner that does the good work in the first phase of discovery. Take special note to the change that is happening here.  Discovery (10+) years ago did actually Ping (NOT ANYMORE) but we found that alot of environments had ICMP shut off and being wholly dependant on that first (ping) step would prevent us from going forward. So we thought, hey why not just skip to a port check, if its successful we obviously have connectivity and we can learn how to come back to communicate (protocol) with it further down the road.

So his post is about the big switch to how we do it today.

Stuart Spreadbo
Giga Contributor

Fantastic. Thank you for the detailed response. Really appreciated and put all my concerns about ICMP being blocked to rest albeit me being 10 years behind you guys 🙂

Great job and loving the platform.