Forum Discussion

AJ_Fasano_1976's avatar
AJ_Fasano_1976
Icon for Nimbostratus rankNimbostratus
Jan 28, 2007

GTM iRule. Is this possible?

First, I am not asking for the iRule. I would actually like to figure it out myself, assuming they are flexible enough for this.

 

 

We need a hybrid topology/RTT type of solution because of issues associated with the probers not being able to query the LDNS servers. Our customer is extremely security consious and there are hundreds of LDNS servers out there which means we will go through this issues of getting FW/ACLs open many many times.

 

 

What I was thinking was a rule that would first evaluate the topology definitions. If the LDNS is not in them it would need to evaluate the various RTTs to the DNS. If there are at least two successful RTT probes, go with the shortest one. If there are less than two, GTM would default to a round-robin pool with hosts that are central to all the possible nodes.

 

 

Is it possible to retrieve the rtt times to the LDNS server that is querying the GTM? I did see a function called ROUTE::rtt and ROUTE::rttvar. Would those be the ones?

 

 

Thanks.

 

 

 

  • Kevin_Jones_505's avatar
    Kevin_Jones_505
    Historic F5 Account
    From my perspective, there are 2 problems with this plan. First, a good set of topology records shouldn't miss any LDNSs. That being said, if you want to "miss" some and use RTT to load balance them, there's something else that sounds iffy. The first time a LDNS sends a probe, GTM cannot use RTT as a load balancing metric. You mention waiting for the probes to return .. how long? If it takes 15 - 20 seconds to get the metrics (and that would be fast), the DNS resolution will take 15 - 20 seconds. That's a very long time.

     

     

    Maybe I don't understand your goal, but you might be able to accomplish what you want without iRules (oops ...shouldn't say that on devCentral!).

     

     

    If you used topology as the primary load balancing method in the pool, RTT as the alternative (when the topology record doesn't exist) and sometime else, even round robin as the fallback, you might get what you want. Queries from LDNSs that match topology records are decided that way. Returning LDNS's that aren't in topology records use RTT. New LDNS's (or those that don't respond to probes) use round robin - without a long wait.

     

     

    Good luck!
  • Believe me when I tell you I was not keen on even proposing the question. But the customer wanted to know so I did it.

     

     

    The problem is this. The customer initially insisted on a purely dynamic global load balancing system. Unfortunately, we later found out that there was little control over LDNS servers and many were behind firewalls and not queryable. They also do not have a clear idea as to where the LDNS servers are so creating a map is a monumental task. The end result was, as you pointed out, when RTT fails it went to RR and was sending people across the globe as opposed to their local node.

     

     

    The customer didnt want to throw RTT away and asked if there was a way we could still use it. The only way I could think of was to create a topology for those we knew about and create an RTT pool for the rest. The only way to ensure that people were not sent to another continent was to see if there was an RTT for at least one non-US continental node and one US node and pick the shorter of the two. In the event there is no good RTT send it to the US since that is as 'central' as we would get.

     

     

    Sadly, this is impossible in an iRule. We have basically settled on topology for pool LB where non-documented LDNS servers always get sent to the US.

     

     

    Thanks for responding. You have actually given me the third party confirmation I was wanted to justify my decision.

     

     

    A.J.

     

  • You could incorporate a rule to do a reverse lookup (assuming this functionality is in GTM rule set? Classes are not in v9.2.x, are they in v9.4?) on the ldns_ip and bind them to a topology record roughly in the vicinity of where that domain is likely to be globally. Not a complete solution, but could potentially address some of the worst case blind decisions.