Akamai provides enormous value by accelerating content delivery around
the world. However, as I described a few months back, Akamai relies on
the DNS server that processes the request to determine where to
accelerate traffic. Large, global corporations often have complex DNS
configurations that can cause Akamai to accelerate content to the wrong
location. For example, they may have users that are located in Europe
but resolve DNS in the United States.
When troubleshooting these issues, it is often necessary to geolocate an
IP address to figure out whether there is a DNS configuration problem.
End users generally don’t know the details of how they access the
internet, and the IT personnel who would know are often hard to reach or
may not know exactly how a specific end user is set up. In these cases,
it’s very helpful to take information about the user’s IP address, their
DNS server, and the IP address of the Akamai edge server they are
hitting and geolocate them to see if there is a mismatch.
Take geolocation databases with a big grain of salt
Geolocating is more art than science. There are many databases that
will attempt to geolocate an IP address, but they can often be error
prone. For example, many of them are based on who registered the IP
address or block and have no bearing on the real physical location.
Let’s take an example: 184.108.40.206. If I use a geolocation service
like www.maxmind.com to look up the location
of this IP address, it will tell me that it is in Cambridge,
Massachusetts. Well, that is very nice of Maxmind to tell us this, but
one thing I can tell you is that this server is very, very far from
However, using a combination of techniques, it is often possible to get
a pretty good sense of where the IP address is. Let’s give it a try.
Start with a traceroute
The first step is to run a traceroute. For example:
C:Usersjrothmanshore>tracert 220.127.116.11 Tracing route to 18.104.22.168 over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 172.29.0.5 2 <1 ms <1 ms <1 ms 172.29.0.2 3 1 ms <1 ms <1 ms 22.214.171.124 4 1 ms 1 ms 2 ms 126.96.36.199 5 1 ms 1 ms 2 ms core2.po2-bbnet2.bsn.pnap.net [188.8.131.52] 6 6 ms 6 ms 6 ms ge11-0-1d0.mcr1.cambridge-ma.us.xo.net [184.108.40.206] 7 16 ms 14 ms 14 ms vb1020.rar3.nyc-ny.us.xo.net [220.127.116.11] 8 16 ms 15 ms 15 ms te-3-0-0.rar3.washington-dc.us.xo.net [18.104.22.168] 9 * 14 ms 13 ms 22.214.171.124.ptr.us.xo.net [126.96.36.199] 10 * * * Request timed out. 11 92 ms 91 ms 89 ms ae-5.r21.sttlwa01.us.bb.gin.ntt.net [188.8.131.52] 12 272 ms 251 ms 248 ms as-2.r21.osakjp01.jp.bb.gin.ntt.net [184.108.40.206] 13 249 ms 239 ms 265 ms as-1.r21.newthk02.hk.bb.gin.ntt.net [220.127.116.11] 14 229 ms 274 ms 244 ms xe-3-2.r00.newthk02.hk.bb.gin.ntt.net [18.104.22.168] 15 323 ms 343 ms 321 ms 22.214.171.124 16 317 ms 326 ms 321 ms 126.96.36.199 Trace complete.
Look at hostnames
One very convenient thing about many ISP’s and backbone providers is
that they tend to name machines based on where the machines actually
are. While the first several IP addresses in the list above don’t tell
me much, at the 6th hop, we hit a machine that indicates that it is in
Cambridge. The 7th hop implies New York City, and the 8th is Washington
If you use a little creativity and imagine routes through the world, you
can make some good guesses about the next couple of hops. I’m pretty
confident that the “sttlwa” in #11 is Seattle Washington. From there, I
would guess that the “osakjp” in #12 is Osaka, Japan. Knowing I am now
in the Asia would lead me to conclude that the “.hk.” in hops #13 and #14 are Hong Kong.
Looks like we are in China. Indeed, very far from Cambridge, MA.
Look at the latencies
Another clue in reading the hostnames is the latency at each of the
hops. I am working out of the Boston area, and in general, I find
latency from traceroutes to different parts of the world to be pretty
- Eastern US takes 15-30 milliseconds
- Western US takes 40-70 milliseconds
- Europe takes 80-100 milliseconds
- Asia takes 200-300 milliseconds
If I compare this with my guesses based on the host names above, I will
see that they work out pretty well. Washington, DC was 16 milliseconds,
which matches my experience for East coast locations. Seattle was 91
milliseconds, a little higher than I normally expect from the west
coast, but not too far off. When I see that latency than jumps up into
the 200 millisecond range at hop #12, it’s a good bet we are in Asia,
and that matches my guess of Osaka, Japan based on the host name.
Check geolocation databases for the last few hops
While the geolocation databases are often pretty far off for the end IP
address, they are much more accurate when used for the nodes of the last
mile ISP’s themselves, which tend to be regional entities.
My preferred sites for lookups is
www.maxmind.com, which provides 25 free
lookups a day. If I try looking up hop #15 (188.8.131.52) in MaxMind
– the one just before my target – I see that it is in Hong Kong and is
managed by the HKNet Company Limited.
All Sources Agree
In this case I now have confirmation from three separate sources that my
target IP address is in China, probably Hong Kong. The hostnames of my
path indicate that we crossed the United States, went over the Pacific
through Japan, and into China. Latency matches my past experience for
an IP address in China. And my geolocation database shows one of my
last few hops in China.
So remember, when geolocating an IP address, don’t just trust what a
database says about last hop. Make sure that the latency numbers and
host names support the theory, and check the last few hops which tend to
be more accurate.