In my previous blog, I referenced the fact that IP proximity databases can be used to distribute Access Gateway SSLVPN (AGEE) load between Global Server Load Balancing (GSLB) sites. These databases are readily available commercially, and can be ordered with varying degrees of content detail. Typically, we all jump on the “more is better” bandwagon – believing that data granularity down to the city level must surely be “better” than only country or state levels. But this self-indulgence in information depth comes at a cost.

In the project I referenced in the previous blog, the IT group had purchased the version of the “database” that contained information all the way down to the city level. I loaded the file into the NetScaler without problem. We set up the GSLB configuration and started to test.

Predictably, I ran into some unexpected routing (see the previous blog “Addressing the Issues”). So now it was time to trace the (DNS) requests and validate the routing. That meant I had to look into the database to validate the location affinity of the requesting IP address.

Simple, right?

There were a couple of surprises that may hit you in doing such a project, just as they did me.

Enormity


The first problem I encountered was how to read this database. Upon looking at the file, I found that it wasn’t a database per se. What I had, in fact, was a formatted CSV flat file. Big – but flat.

Import it into a spreadsheet, right?

Well, it turned out to be too big for Microsoft Excel!

So, as a next step, I simply uploaded the file into Microsoft Access. That “simple” import brought over 2.9 million records into the database table! Good thing I used a database manager.

Furlongs Per Fortnight

Once imported I was ready to go. To my surprise, when I browsed the database table, I found long numeric strings in the “from-IP” and “to-IP” fields. Then, looking at the readme file (who ever looks at that first?), I noted that the IP address ranges were specified using the decimal notation of the IPv4 address.

A converter was easily created using a simple Excel spreadsheet to calculate the decimal format. So now I could find the location of an IP address captured in the Wireshark trace.

Never Ending Scrolls

Once I had the formatting problem licked, I found, however, that locating a specific IP address’ range was a scrolling challenge. Remember that the database contained over 2.9 million records. So I knew it was time injected some SQL queries, so to speak. Actually, I created a simple ad-hoc SQL query that used the IP address from the trace to find the database table record with the range containing that IP address. This query selected and returned the appropriate record, complete with location.

With that, I was able to validate DNS server IP address to locations to my heart’s content.

To Wrap Up

As I stated earlier, in blogs to come, I’ll continue to discuss some of the other “interesting” considerations that come with implementing GSLB. All based upon my experiences, of course. Additionally, I’m working on a more formal document that will include some detailed recommendations and some trouble shooting tips.
Stay tuned.

I welcome your comments or experiences in the GSLB arena.

Stefan
Twitter: @StefanDrege
Ask The Architect: AtA