GTM Probe of LDNS - what is the use case ?

Hi,

When a client makes a DNS lookup using its local recursive DNS (LDNS), that LDNS is the device that makes the query to the GTM, so the GTM (with the exception of recent additions to the DNS protocol), has no way to know what the original client's IP address was, but in many cases, the IP address of the LDNS is somewhat related to the client's IP. They tend to be in the same country, or regional area, because an ISP wants their DNS servers to be as close as practical to the users to reduce DNS lookup time.

So the round trip from a data centre to an LDNS can be used as an approximation for the experience that the user would observe. To do this, you can set the preferred load balancing method for the GTM pool to one of the dynamic methods, for example, Round Trip Time, Hops, Packet Loss. Selecting one of these methods causes the GTM to send out probes to the LDNS servers, once we receive a request from them. Note that the Alternate load balacing method drop box does not contain any of the dynamic methods, as there has to be a non-dynamic method available for the first few request, since we won't have the LDNS probe data when the first request from that LDNS arrives at the GTM.

The configuration related to LDNS metric collection is under DNS / Settings / GSLB / Metrics Collection, and you can select the type of probe the GTM should send. By default, it's just a ping, but we also support a TCP connection, a UDP connection, and two types of DNS queries.

The use case here is that if you had two GTMs in two data centres, say East Coast and West Coast of the US, and the probe RTT for the East Coast GTM was 60ms, but the RTT for the same LDNS from the other DC was 260ms, then the GTM can infer that the client is much closer to the East Coast DC, and that the client that used that LDNS would likely be best served with a response from a device in the East Coast.

For more information about this, and more complete descriptions of the dynamic methods, please refer to this manual page

Thanks you have answered the question I meant to ask ;-) … understand that one now.

Couple more if I may

Q1. RE probes does “path” = latency.

RE prober pools from BIG-IP_Global_Traffic_Manager__Concepts-11.6

… from what I read ; A prober pool essentially sets up a GTM to pull statistics / data from host end points using defined LTMs to contact the hosts (in the same prober pool) gather stats and pass to GTMs to make LB decisions.

If we do not have a prober pool defined apparently the GTM will solicit random (round robined?) LTMs to probe GTM defined generic host servers.

Q2. Why does the GTM use an LTM to perform a probe where a host server is not in a prober pool – the generic server is defined on the GTM why does the GTM not probe it itself ?

Q3. Say if there were no LTMs in the environment how does probing work?

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.

OK cool .

Is it true to say that if I create a generic host server on the GTM with a monitor with no prober pool that the GTM will always mediate this "probe"?

The only reason I ask is that the example in the doco apparently has this scenario BUT has the GTM soliciting an LTM(s) to perform the probe and I cannot work out the (GTM-LTM) connection here … unless it is the case that any GTM with a trust set up with an LTM will de facto hit up an LTM to off load monitoring.

https://support.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/gtm-concepts-11-5-0/4.htmlunique_422805764

Don't get focused on the BigIP being a GTM or an LTM, or an ASM etc. Think of it more that any BigIP product is also a big3d agent, and it's the agent that gtmd uses to carry out the health check.

The list of big3d agents available is defined as 'all devices in the gtm server list that are type BigIP (or redundant BigIP)'

All monitors that need to be run are allocated to a gtmd processes through a simple hash, and (except for bigip monitors), the gtmd processes allocate the checks to big3d agents, preferring agents that are in the same data centre as the monitor target.

So in regard to your question, if you create a generic host, and assign a gtm http monitor to it, and you have only one GTM in your environment, then the gtmd process on that GTM will assign the monitor to any big3d agent available in the same data centre (which could be itself). If the load on all agents exceeds a threshold, it will also consider big3d agents in other data centres. If a prober pool is assigned, it will limit the available choices to big3d agents on the devices specified in the prober pool.

Beautiful .. Thanks.

after some reading this will show you the way. i hope it helps. it helped me.

https://support.f5.com/kb/en-us/products/big-ip_gtm/manuals/product/bigipgtm9_4config/BIG_IP_9_4_GTM_Config_gd-17-1.html https://support.f5.com/kb/en-us/solutions/public/6000/400/sol6480.html