Excuse me for a moment while I geek out. Ahem.

The numbers that follow are traceroute latency figures in milliseconds from resolving www.akamai.com.

Numbers at the end in parentheses represent the total average (for multiple runs) of the 1st column of millisecond ping measurements.

Akamai's distributed, load-balanced DNS system is intended to optimize, based on a number of factors, the closest and fastest server from which to serve content.

DEFAULT DNS Server: 68.238.0.12 (Verizon's peering/transit)

1 <1 ms <1 ms <1 ms 192.168.2.1
2 24 ms 24 ms 23 ms L100.DSL-01.SBNDIN.verizon-gni.net [71.115.0.1]

3 37 ms 36 ms 37 ms at-1-0-0-133.CORE-RTR2.CHI01.verizon-gni.net [13
81.36.74]
4 37 ms 36 ms 36 ms 130.81.20.58
5 31 ms 31 ms 32 ms 130.81.19.52
6 55 ms 55 ms 55 ms 130.81.16.9
7 54 ms 55 ms 55 ms 130.81.18.91
8 56 ms 55 ms 55 ms 130.81.64.53

(295 ms)

DNS Server: 205.171.6.65 (Qwest-owned)

1 1 ms 1 ms 1 ms 192.168.2.1
2 25 ms 23 ms 23 ms L100.DSL-01.SBNDIN.verizon-gni.net [71.115.0.1]

3 27 ms 26 ms 25 ms 130.81.36.72
4 26 ms 25 ms 25 ms 130.81.20.56
5 26 ms 26 ms 25 ms 130.81.16.11
6 26 ms 26 ms 26 ms so-3-3-0-0.e2.Chicago1.Level3.net [4.79.210.5]
7 26 ms 26 ms 26 ms ge-6-0-0-53.edge1.Chicago1.Level3.net [4.68.101.
]
8 26 ms 26 ms 26 ms 65.59.88.194
9 27 ms 26 ms 27 ms Vlan2.msfc1.CT8-Chicago.teleglobe.net [66.110.15
]
10 26 ms 26 ms 26 ms 64.86.101.102

(236 ms)

Problem: As you can see, the default DNS server, obtained via a standard DHCP lease, is actually (again, on average,) 59 milliseconds slower than the Qwest one I added manually. No, this doesn't really matter in reality.

Solution: Use Qwest's DNS (or Speakeasy.net's Chicago one, 64.81.159.2)

What I thought I'd point out, however, is that, regardless of total latency, it always appears to pick the route with the shortest AS hop count (gee, this reeks of BGP).

Generally, vanilla-installed BGP configs of multi-homed peering/transit providers are limited by the protocol, which is why entire separate companies existed in the past to address this problem:
* netVMG, which is now incorporated into the Internap line, in their Flow Control platform.
* Sockeye, which is also now incorporated into the Internap line, in their Flow View platform.
* RouteScience, now incorporated into Avaya's Converged Network Analyzer product.

The problem with BGP version 4 is that its routing decisions are largely based solely on AS hop count, so factors like latency, brown outs, packet loss, etc. are ignored.

Good article on BGP's limitations and multi-homing in general here.

About this Entry

This page contains a single entry by Stephen Donner published on December 26, 2005 1:06 AM.

was the previous entry in this blog.

is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

Powered by Movable Type 5.12