We’ve been using F5 GTM’s (global traffic managers - DNS based load balancers) for the last year or so at work, and have slowly been deploying new applications on them.  In our environment, we heavily utilize topology records to send users to the closest instance of an application.

We’ve come across some interesting things about how the GTM evaluates topology records that weren’t immediately obvious to us, or that we figured out through trial and error.

I’d be curious to here how other people use topology records.  We are planning on trying to keep the number of topology records to a minimum to make it easier to manage.  We also will be trying to not reference any regions that may overlap when creating topology records for a particular application.

I’ll use some examples in my notes below, based on these assumptions:

  1. A Wide IP is configured for app1.example.com, with two pools, APP1-POOL1 and APP1-POOL2.  Topology load balancing is being used.

  2. Three regions are defined:

     1. REGION-A:  192.168.0.0/16; 10.0.0.0/8
 2. REGION-B:  192.168.0.0/24; 172.16.0.0/16
 3. REGION-C:  192.168.5.10/32; not 192.168.0.0/16

Here are some of the notes I’ve made about topology records as I’ve become more familiar with the GTM’s. In our environment, all of our topology records use a “region” for the source, and either a data center or pool for a destination. Some of these “lessons learned” may not apply 100% to other environments that use topology records differently.

  • Topology load balancing can be used at two levels - Wide IP level (when selecting between pools), and pool level (when selecting between virtual servers)

  • Topology records with a datacenter as a destination only apply at the pool level (when selecting virtual server) - not at the WIP level.  Pools are not directly associated with a data center (servers are).  Pools can contain virtual servers from multiple data centers.

  • Inside of a region - “is not” / exclusions take precedence over “is” / inclusions (regardless of mask length, or the type of match).  So, REGION-C would not be matched for DNS requests coming from 192.168.5.10.  Even though that IP is specifically included, the blanket exclusion on 192.168.0.0/16 appears to prevent it from being matched.

  • Regions that are included in other regions work as I expected.  With topology rules that reference the parent region, members of the child region are treated the same as if they were directly included in the parent region.

  • “Longest match” just sorts the topo records by source.  For records that have an IP as a source, it does sort longest mask to shortest mask.  However, it treats a region as a single entity - it doesn’t do longest matching within a region.  So, if one region is matched based on the country, and another region matches based on an IP - those matches are treated equivalently.

  • The destination with the highest weight will win - however, because of how the GTM assigns a weight to a pool, that does not necessarily mean that the highest weighted record will win. (See the last bullet point).

  • If multiple destinations with the same weight are matched (and have the highest weight of all matched destinations) - GTM will round robin between those two destinations.  For example, using the WIP / region’s I listed above, with these topology records:

    Source Destination Score
    REGION-A APP1-POOL1 20
    REGION-B APP1-POOL2 20

  • DNS requests for app1.example.com coming from 192.168.0.5 would be round robin load balanced between APP1-POOL1 and APP1-POOL2.

  • When multiple topology records match for a given request, with the same destination - the GTM will use the first weight for each of the destinations when deciding which destination to send traffic to.  This was not immediately obvious to me.  I think of this as a two step process.

    1. When a DNS query is received, the GTM first evaluates the topology records to assign a weight to each destination.  The first matching record with a given destination determines the score that is assigned to that destination.
    2. Following that, the GTM selects the destination that has the highest weight.

  • So, with the following topology records:

    Source Destination Score
    REGION-A APP1-POOL1 30
    REGION-A APP1-POOL2 20
    REGION-B APP1-POOL1 10
    REGION-B APP1-POOL2 40

  • If a request comes for app1.example.com comes from 192.168.0.5, all four of these records would be matched.  When evaluating the records, the GTM would assign a score of 20 to APP1-POOL2, and a score of 30 to APP1-POOL1.  So, the the GTM would use APP1-POOL1 when responding to the DNS request.  This might seem counter-intuitive, because POOL2 has a matching topology record with a score of 40.  However, that record is never actually used, because the GTM has already assigned a score to POOL2 by the time it evaluates it.

  • If we change this scenario slightly, by removing the topology record for REGION-A / POOL1, we’ll see a different result.

    Source Destination Score
    REGION-A APP1-POOL2 20
    REGION-B APP1-POOL1 10
    REGION-B APP1-POOL2 40

  • When evaluating these records, the GTM would assign a score of 20 to APP1-POOL2, and a score of 10 to APP1-POOL1. So, the the GTM would use APP1-POOL2 this time when responding to the DNS request.

For some other information on topologies records, I’d recommend these F5 KB articles:

GTM Topology records in 11.x

Topology Records Longest Match Option