F5 GTM Topology Records – Lessons Learned
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:
* 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:
If we change this scenario slightly, by removing the topology record for REGION-A / POOL1, we’ll see a different result.
For some other information on topologies records, I’d recommend these F5 KB articles: