What is GTM
Global Traffic Management, or GTM, is a DNS-based load balancing service that offers application owners a level of flexibility and insight that is unmatched by traditional on-prem solutions. Highly scalable and fault-resilient, GTM offers customers a layer of abstraction between endpoints, so traffic can be easily shifted between targets. The platform is not limited to weighted load distribution, however; GTM can execute intelligent routing decisions based on client location, network conditions, and even origin server availability. These features are possible thanks to Akamai’s unrivaled visibility into the Internet, which fuels the platform’s dynamic, data-based route optimization engine.
This blog post will focus specifically on GTM’s Geo-IP intelligence feature, and how the Akamai platform addresses a known limitation of the DNS protocol concerning end-user geolocation detection.
DNS and Geolocation Limitations
The minimalist nature of the DNS protocol frequently presents challenges for more complex load balancing requirements. One great example: application owners often want to configure DNS traffic management platforms, such as GTM, to dynamically execute handout decisions based on the location of the end user — information that is derived from the client IP address. However, incoming DNS queries typically only advertise the IP of the requesting recursive resolver and do not disclose the true client IP. While the local recursive resolver is typically proximal to the requesting machine, geolocation detection can be distorted when a distant proxy server is performing a DNS lookup on behalf of an end user. Unlike HTTP, DNS has no ‘X-Forwarded-For’ equivalent, so the true initial client IP will be invisible to the responding nameserver, complicating any geo-routing decisions. For example, in the image below, the nameserver cannot evaluate the IP of the end user (22.214.171.124); it only has insight into the recursive resolver address (126.96.36.199):
From an Akamai perspective, this scenario is applicable when an Akamai edge server is performing a DNS lookup against a GTM property to determine which ‘origin’ datacenter is best suited to respond to a client request. This setup is commonly classified as ‘back-end’ GTM, which is illustrated by the second circle below:
Akamai’s GTM includes IP intelligence that can ascertain the location of the client’s recursive resolver. Application owners can thus configure traffic routing decisions based on this information to direct end users to the most geographically appropriate data center. However, with back-end GTM, an Akamai server queries the GTM property, so the GTM nameserver will only have insight into the location of this edge node (and not the true end user). Luckily, with a quarter of a million edge servers located across 234 countries, the impressive footprint of the Akamai platform ensures users are intelligently routed to a geographically proximal edge server. As a result, location-based handout decisions remain as accurate as possible when back-end GTM is in place.
But what happens when multiple Akamai servers are introduced? One of the primary features of Akamai CDN is the two-tiered cache hierarchy. If an initial edge server does not possess a cacheable file in disk or memory, the request will be forwarded to another Akamai server (referred to as a ‘Cache Parent’) to maximize the chances of returning a cache hit:
If the object is also not available in cache at this stage, this second “parent” server will perform the ‘back-end’ DNS lookup against a GTM property to discover the pertinent origin IP. While this tiered distribution model is optimal from an offload perspective, adding an additional Akamai hop to the request flow complicates GTM’s visibility into the end user’s true location, as there is no guarantee the second Akamai server will be in the same approximate region as the initial edge node (called the ‘child’ server pictured above). Without any accommodations, GTM IP Intelligence will thus route the request based on the location of the parent server, which is not ideal.
To address this DNS limitation, Akamai has developed metadata tags to ensure back-end GTM geolocation logic is interoperable with tiered distribution. These tags instruct the platform to always execute the origin DNS lookup on the initial child Akamai server, and the result will be passed to the subsequent parent in case an origin server needs to be contacted. This ensures geo-based GTM decisions remain accurate since the child server is a superior geographical surrogate for the end user.
Akamai’s Application Load Balancer (ALB)
With Akamai’s expansive, distributed network and the aforementioned metadata tags, back-end GTM geo-routing remains accurate if the geographic traffic routing decisions are evaluated at a country or continent level. However, if more granular logic is required (such as state or city), Akamai’s Application Load Balancer Cloudlet includes layer seven geolocation targeting. Unlike GTM, ALB has insight into HTTP request criteria, which allows the cloudlet to ascertain the location of the true end user. Consequently, if geo targeting needs to be executed at a state, county, or city level, ALB is a preferable solution. Along with heightened visibility into the end-user’s location, ALB offers additional layer seven traffic management capabilities, such as session affinity and instant failover.
ALB Plus GTM
While ALB offers additional layer seven faculties, GTM has unique capabilities as well, including the ability to execute traffic decisions before an HTTP request is made (Front-End GTM). Consequently, depending on the application owner’s requirements, either solution may prove a better fit, and it is even commonplace to use both! There will be many architectural situations where an organization will have GTM deployed to cover the resiliency for some functions and ALB deployed to cover specific applications. The combination of ALB and GTM provide DevOps, network architects, and system engineers with the flexibility to choose the optimal cloud-based GSLB solution. Some applications architects might need cloudlet ALB functionality to manage in-line experiences that Akamai delivers. At the same time, network architects for that same company might need to shape traffic between multiple cloud deployments and providers. With GTM and ALB, system engineers and application developers have full control.
Find out More about Akamai’s GTM and ALB
Use the “Get in Touch” icon on Akamai.com to chat with someone in Akamai right now to find more information about Akamai’s GTM and ALB services. The following are some additional links to materials.
 When enabled, the tiered distribution model only applies to cacheable objects.. Non-cacheable requests are typically subject to Akamai’s SureRoute feature, which always executes the origin DNS lookup at the child stage. Thus, these tags are only needed for cacheable files
 These tags are also applicable when Site Shield is in place, which provides a concrete subset of parent servers for security purposes
 The optimal Akamai edge server is also determined via a DNS lookup initiated by the true client machine (circle #1). A GTM property can also be used in this stage as well (Front-End GTM)
 Certain recursive DNS providers have implemented an extension (EDNS0) to pass the source IP information of the actual machine requesting the DNS record. However, the aforementioned proxy implementation can still distort DNS geo detection logic since the initial true client IP will not be visible in this scenario
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Sam Preston. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/-lKY7eP9-Hg/geolocation-and-dns-traffic-management.html