New Geolocation Capabilities in v10.1

With the BIG-IP GTM and 3-DNS products, location-based service has existed in the form of topology-based load balancing.  The possibilities grow exponentially in v10.1, as you now have the capabilities in GTM and LTM.  In this tech tip, we’ll discuss the iRules command access, the update procedures for keeping your data current, and some use cases for consideration.

Introduction

The level of detail has grown from continent and country on GTM to continent, country, state (or similar provincial boundaries outside the U.S), carrier, and organization, available on GTM and on LTM and other modules with iRules access.  There are native GUI tie-ins in the GTM, but if using in iRules, the command usage is actually quite simple:

[whereis [IP::client_addr]] – returns a list with continent, country, state, and city (not yet available)
[whereis [IP::client_addr] continent] – returns the continent
[whereis [IP::client_addr] country] – returns the continent
[whereis [IP::client_addr] <state|abbrev>] – returns the state information as word or as two-letter abbreviation
[whereis [IP::client_addr] isp] – returns the carrier
[whereis [IP::client_addr] org] - returns the registered organization

 

If looking up several levels, a quick performance check revealed that setting the list to a single variable and using lindex is 3x more efficient than using the whereis keywords.  Note that unavailable data will be returned as an empty string for these fields.

Updating Your Geolocation Data

Previously, to update your location data required a TMOS version upgrade.  Now, the updates are released frequently and made available at https://downloads.f5.com.  Also, if you want to use the org keyword with the whereis command, you’ll need to download the update or you’ll get an error during execution.  The F5 schema supports additional data fields that are documented on the wiki page that will be available in the future.  You can experiment with the commands now—it will simply return an empty string or a zero.  Sub state granularity requires data not included by default on BIG-IP.  Contact F5 sales if you are interested in more detailed granularity. 

To get started, go out to the downloads site, select the latest zip file, download it, then extract locally and then upload the RPMs to the LTM (or upload the archive and use unzip on the BIG-IP).  I extracted locally and used Putty’s pscp executable:

C:\Users\rahm\Downloads>pscp geo*.rpm root@172.16.99.128:/var/tmp/
Using keyboard-interactive authentication.
Password:
geoip-data-ISP-1.0.0-2010 | 2398 kB | 2398.5 kB/s | ETA: 00:00:00 | 100%
geoip-data-Org-1.0.0-2010 | 53565 kB | 6695.7 kB/s | ETA: 00:00:00 | 100%
geoip-data-Region2-1.0.0- | 12708 kB | 4236.0 kB/s | ETA: 00:00:00 | 100%

Now that you have the files local, you can install them:

[root@localhost:Active] tmp # ls | grep geo.*.rpm
geoip-data-ISP-1.0.0-20100201.28.0.i686.rpm
geoip-data-Org-1.0.0-20100201.28.0.i686.rpm
geoip-data-Region2-1.0.0-20100201.28.0.i686.rpm
[root@localhost:Active] tmp # geoip_update_data geoip-data-ISP-1.0.0-20100201.28.0.i686.rpm
[root@localhost:Active] tmp # geoip_update_data geoip-data-Org-1.0.0-20100201.28.0.i686.rpm
[root@localhost:Active] tmp # geoip_update_data geoip-data-Region2-1.0.0-20100201.28.0.i686.rpm

For further details on the usage of the geolocation database, reference Solution 11176, the TMOS Management Guide, and the Configuration Guide for GTM.  All three documents require support logins.

Use Cases

There are many use cases for utilizing geolocation data, but we’ll look at just a few below.  First, there are a couple things to note on the use of the geolocation data.  Yep, we’re talking EULA.  The data is purchased by F5 for use on BIG-IP systems and products for traffic management.  The key to understanding EULA compliance is to figure out where the geolocation decision is being made.  It is a direct violation of the EULA to use F5’s data to embed geolocation information or codes representing geolocation information into the requests such that another application or server could make the decision on what to do with that data.  Customers wishing to use geolocation data on their webservers or in their applications to make decisions in those products should reach out their account team for guidance.  F5’s traffic management products have a lot of power and flexibility and can make lots of decisions about traffic using the geolocation data on the BIG-IP.  For example, a geolocation lookup can be used to route traffic requests to a different site, different server, different URL, or even substitute a different image, object, etc in the stream.  The key is that the BIG-IP is making use of the data to make a decision to take some action.  These are all allowed and in fact, intended usage of the geolocation data.  Passing the data looked up to another system or displaying it back publicly is a violation of the basic data EULA.  To summarize, all usage of the data must remain local to the system with the following two exceptions:

• Location can be placed in an encrypted cookie for reference ONLY by other BIG-IP devices
• Logging data can contain location info and collected into a central logging solution for analysis of F5 logs.

Note that you can get a waiver of the EULA.  In the near future, F5 expects to have expanded data sets available with less restrictions on the use cases.  If you’re unsure, run your use case by your sales engineer.

Localizing Content

Many websites have the language options featured top-right, footer, or sometimes in the navigation itself.  You can still make this option available (case in point, I was in Belgium on business a couple weeks ago but much prefer to read my sites in English, thank you) but now with LTM access you can auto-switch the content.

when CLIENT_ACCEPTED {

  switch [whereis [IP::client_addr] country] {

    US { pool usa }

    CA { pool canada }

    MX { pool mexico }

    default { pool northamerica }

  }

} 

Regulatory Compliance

Perhaps you face restrictions on where your clients can access your application from.  This iRule will prevent users not originating from Missouri or Illinois from accessing the application

when CLIENT_ACCEPTED {

  if { !(([whereis [IP::client_addr] abbrev] equals "MO") or ([whereis [IP::client_addr] abbrev] equals "IL")) } {

    pool rejected

  }

}

Redirecting to Closer Geography

This is one use case that solves some of the difficulties in global load balancing.  With gslb, accuracy of geographic distribution relies on well-designed ldns infrastructure.  I know several entities where all ldns is centralized, which leads to problematic distribution.  Now, you can analyze at the local level and redirect accordingly.  Assuming you built a data group with all the states split into regions (ie, “MO” := “midwestpool”), you could build a simple irule to make sure your clients use the datacenter nearest them.

when CLIENT_ACCEPTED {

    set region [class match -value [whereis [IP::client_addr] abbrev] equals us_regions]

    if { $region ne "" } {

        switch $region {

            midwest { pool $region }

            east { HTTP::redirect http://my-east.application.com }

            south { HTTP::redirect http://my-south.application.com }

            west { HTTP::redirection http://my-west.application.com }

    } else { pool default }

}

Another way you might approach that:

when HTTP_REQUEST {

    set region [class match -value [whereis [IP::client_addr] abbrev] equals us_regions]

    if { $region ne "" } {

        if { $region equals "midwest" } {

            pool $region

        } else { HTTP::redirect http://my-$region.application.com }

    } else { pool default }

}

*Note—all these iRules are conceptual in nature and are untested.

Conclusion

Accurate, updatable geolocation data, integrated into BIG-IP.  We’re really just scratching the surface here.  Exciting things to come, stay tuned.