Forum Discussion

martin_58353's avatar
martin_58353
Icon for Cirrus rankCirrus
Feb 07, 2017

BIG-IP DNS - dynamic LB method "hops"

I'd like to ask you for details about dynamic LB method "hops". Documentation description is nice and short, but without details:

 

"BIG-IP GTM distributes DNS name resolution requests to a virtual server in the data center that has the fewest router hops from the client's LDNS. BIG-IP GTM uses the traceroute utility to track the number of router hops between a client's LDNS and each data center."

 

The question is, how can GTM to know the number of hops between client's LDNS and each data center. I think, there is only one possibilities: the number of hops between client's LDNS and datacenter is summary of hops between (GTM and LDNS) and (GTM and data center).

 

If it's true, not always will be decision correct. For example: client and first data center is in the same city (second DC and GTM in another city). traceroute between client's LDNS and first DC is 'one hop', but GTM calculates calculates GTM-to-LDNS as 2hops and GTM-to-first-DC as 2hops. in summary 4hops for first DC. for second DC is GTM-to-LDNS 2hops, and GTM-to-second-DC 1hop. in summary 3hops. in the final client's request is routed to second DC (3 hops) and not first DC (1 hop).

 

can anybody (f5 technician) explain me this dynamic method?

 

thanks, martin

 

application delivery
BIG-IP DNS

1 Reply

Sort By
  • IanB's avatar
    IanB
    Icon for Employee rankEmployee
    Feb 09, 2017

    Every BigIP device (GTM or LTM) referenced in the GTM config as a gtm server object is a big3d agent. Each gtm server is configured to be in a specific data centre. So from that, we know which data centre each big3d agent is in.

    LDNS probes are sent from a one big3d agent in each data centre, so that GTM can pick the correct data centre for each LDNS. It's an entirely separate mechanism from the normal GTM monior probes, so doesn't follow the normal gtm probe rules, though it does still use big3d/iquery to request the probe be run, and to retrieve the results.

    LDNS probes only run when there's configuration that requires it. The first query from an LDNS will always fall through to one of the static (non dynamic) load balancing methods, as the BigIP won't have the LDNS information at that time, and kicks off a background process to go out and collect the dynamic information, as required by the GTM configuration.

    Once we have the first results, we continue to update that dynamic data at regular intervals, as long as the LDNS keeps sending requests (gtm global-settings metrics ldns-update-interval) seconds. We'll hold on to data for up to (inactive-ldns-ttl) seconds (default 2419200 - 28 days)

    Every (gtm global-settings metrics metrics-caching) seconds, we write the current dynamic data out to /config/gtm/ldns.gz so that it can be read in on the next bootup, avoiding the need to run initial probes for everything again.

    Here's an example of the ldns.gz file's contents with one wideip using a pool set up for a load balancing method of hops. My LDNS is 5.1.0.103 in this case.

    [root@gtm-1211-hf1-143:Active:Standalone] gtm  zcat /config/gtm/ldns.gz
path {
   address            5.1.0.103
   datacenter          "/Common/dc1"
   cur_hops            10
   cur_last_hops       1486598180
   probe_protocol      icmp
   last_used       1486599277
}