Forum Discussion

JD1's avatar
JD1
Icon for Altostratus rankAltostratus
Sep 15, 2015

GTM Query - Global Availability clarification.

Hi All,

 

Reading the documentation, I see (what I expect Global Availability to do)...

 

"BIG-IP GTM distributes DNS name resolution requests to the first available virtual server in a pool. BIG-IP GTM starts at the top of a manually configured list of virtual servers and sends requests to the first available virtual server in the list. Only when the virtual server becomes unavailable does BIG-IP GTM send requests to the next virtual server in the list. Over time, the first virtual server in the list receives the most requests and the last virtual server in the list receives the least requests."

 

In the case of a Wide IP it'll select the first available pool. In the case of a pool, it'll select the first available virtual server.

 

As I gather, the first being order number 0 then 1, then 2 and so on.

 

So here's my setup:

 

  • Wide IP (Method Global Availability) -> Single Pool -> Two virtual servers.
  • Single Pool configured with Pref: Global Availability, Alternate: None, Fallback: Fallback IP: The IP of the first VS in the list.
  • There's no monitoring against the pool, or dependencies. So both virtual servers are green, so is the pool.

Looking at the DNS resolutions, it seems quite often the second in the list is being returned.

 

Why is that, when the first isn't down?

 

Thanks,

 

JD

 

availability
BIG-IP DNS
dns
management
wide ip

1 Reply

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

    That certainly doesn't seem right. I would expect only the first pool member to be returned.

    If you're running GTM 11.5 or later, try enabling decision logging on the WideIP. You'll need to create a log publisher 

    (system / logs / config / publishers / create / destination: local-syslog)
    , then create a DNS logging profile 
    (DNS / delivery / profiles / other / dns logging )
    , then associate that logging profile with the DNS profile associated with your listener. If you're expecting a lot of traffic, it may pay to create a new listener IP address, and associate that with a DNS profile with logging enabled specifically for debugging.

    Once that's done, edit the wideip, set advanced, and turn on the tick boxes at the bottom.

    Note that the local-syslog destination will write to /var/log/ltm, not /var/log/gtm.

    Doing that should produce something like this, which should identify why the answer was given.

    Feb  9 00:29:16 localhost info tmm[10144]: 2016-02-09 00:29:16 gtm-1160-42.local from 172.16.218.1037497: view none: query: www.example.org IN A +E (172.16.218.42%0)

    Feb  9 00:29:16 localhost info tmm[10144]: 2016-02-09 00:29:16 gtm-1160-42.local from 172.16.218.1037497 [www.example.org A] [round robin selected pool (pool_http_irule)] [pool member select check failed (172_16_218_100:172.16.218.100) - pool member is disabled] [round robin failed to select a pool member] [failed to select pool member by preferred load balancing method] [Using none load balancing method] [failed to select pool member by fallback load balancing method] [round robin failed to select a pool]

    Note that you'll only get the decision log if GTM handled the query. If it was passed through to bind (named), you'll only see the query (and you'll only see that if query logging is ticked in the dns logging profike)