GTM Probe of LDNS - what is the use case ?

POOL_CONFIG->rtt * (GLOBALS->rtt / path->rtt) * 10 +

path refers to the path between the big3d agent and the LDNS. path->rtt refers to the round trip time of that path.

A prober pool is only needed when your network only allows specific BigIP devices (big3d agents) to successfully monitor particular hosts. Without a prober pool, gtmd will distribute the gtm monitor requests evenly to big3d agents in the same data centre as the host, unless they're too busy, in which case it will overflow to big3d agents in another data centre. If your firewalls mean that an LTM (for example) in DC1 would be unable to successfully run monitor requests for a device in DC2, then you can create a prober pool containing the BigIP objects in DC1 only, and then assign it to that gtm server.

However, do note that BigIP targets (a device of type bigip - where the monitor is also 'bigip') are a special case - for these, prober pools are ignored, since the only device that can provide information about the device's monitor status is the device itself.

To put that a different way, the bigip monitor uses iquery to ask an LTM what the LTM monitor status is of all the virtual servers, and then applies that status to the gtm server / virtual servers objects. This means that you don't need to double up your monitoring - in effect the GTM is cheating by just using the LTM monitor results.

For non BigIP devices, such as generic-hosts, you would need to apply an appropriate gtm monitor, such as HTTP, and that's where prober pools come in.

The big3d agent runs on all BigIP devices, including GTMs, so there is always at least one big3d agent (on the GTM itself). gtmd maintains an iquery (tcp/4353) connection to all big3d agents, including to the one running locally on the GTM.