 odogCable Centric Vendor BiasedPremium,VIP
join:2001-08-05
Atlanta, GA
kudos:5
 ·Comcast
| reply to espaeth
Re: [Connectivity] ibone vs cbone said by espaeth:said by iansltx:Hmm, usng 4.2.2.x for my DNS servers as they're faster than Comcast's. wonder if hat's causing routing issues. I'd tend to thin no though...traceroutes to www.comcast.net coming shortly... Akamai doles out DNS resolutions based on network information of the server making the request. Using central DNS services like OpenDNS and Level(3)'s (4.2.2.x) will likely get you faster resolution, but unfortunately for CDN solutions it will get to you the cache closest to their resolving server and not necessarily the cache closest to you. actually that IP exists in many locations, via anycast. Most people are only a few hops away from it, but take vastly different paths, and end up at "different" versions of that same IP.
»en.wikipedia.org/wiki/Anycast |
|
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Clear Wireless
| 
OpenDNS Cache Check |
said by odog:actually that IP exists in many locations, via anycast. Most people are only a few hops away from it, but take vastly different paths, and end up at "different" versions of that same IP. Anycast doesn't change the fact that the edge resolvers are not all configured for independent recursive searches. The public facing resolvers are still setup to forward queries to upstream caches to gain more efficiency from parallel hits.
I've attached a lookup from OpenDNS (»www.opendns.com/support/cache/ )who also uses Anycast with central lookup pooling to demonstrate my point. You can see that New York, NY and Seattle, WA are returning the same results for www.google.com. That should be your first clue something isn't quite right.
Take one of the Chicago IPs:
traceroute to 74.125.77.103 (74.125.77.103), 30 hops max, 40 byte packets
1 69.65.40.62 (69.65.40.62) 84.147 ms 84.111 ms 84.107 ms
2 v998.csr2.Chi3.Servernap.net (69.39.239.177) 0.544 ms 0.550 ms 0.548 ms
3 xe-5-0-0.er1.Chi2.Servernap.net (66.252.0.70) 1.570 ms 1.572 ms 1.571 ms
4 56.ge1-12.tsr1.ord1.us.vxl.Servernap.net (66.252.3.142) 1.569 ms 1.565 ms 1.564 ms
5 * * *
6 216.239.48.154 (216.239.48.154) 2.031 ms 209.85.250.237 (209.85.250.237) 2.026 ms 216.239.48.154 (216.239.48.154) 2.019 ms
7 216.239.46.49 (216.239.46.49) 25.420 ms 34.394 ms 216.239.46.15 (216.239.46.15) 23.311 ms
8 64.233.175.212 (64.233.175.212) 128.316 ms 209.85.255.140 (209.85.255.140) 25.434 ms 209.85.255.138 (209.85.255.138) 25.415 ms
9 72.14.236.217 (72.14.236.217) 128.788 ms 72.14.236.213 (72.14.236.213) 25.440 ms 216.239.43.123 (216.239.43.123) 139.098 ms
10 66.249.95.130 (66.249.95.130) 130.305 ms (209.85.130.84) 128.102 ms 128.020 ms
11 209.85.248.80 (209.85.248.80) 142.260 ms 209.85.255.98 (209.85.255.98) 143.405 ms 209.85.248.80 (209.85.248.80) 139.825 ms
12 209.85.248.79 (209.85.248.79) 139.419 ms 72.14.233.114 (72.14.233.114) 310.732 ms 308.542 ms
13 209.85.255.143 (209.85.255.143) 141.862 ms 209.85.255.166 (209.85.255.166) 138.303 ms 139.747 ms
14 209.85.255.98 (209.85.255.98) 145.525 ms 209.85.255.102 (209.85.255.102) 148.485 ms 209.85.255.98 (209.85.255.98) 158.177 ms
15 ew-in-f103.google.com (74.125.77.103) 140.976 ms 139.564 ms 140.525 ms
OpenDNS's results put me 140ms away (with dismally few PTR clues as to where you end up. This trace shows it actually lands me in the UK:
traceroute to 74.125.77.103 (74.125.77.103), 30 hops max, 40 byte packets
1 v628.core1.mnc1.uk.razorblue.com (86.53.206.129) 1.204 ms 1.485 ms 1.778 ms
2 razorblue.ifl.telecomplete.net (213.160.121.197) 0.764 ms 0.792 ms 0.263 ms
3 v700-r3.tcw.telecomplete.net (213.160.116.54) 1.837 ms 1.806 ms 1.777 ms
4 v951-r1.tch.telecomplete.net (193.0.255.198) 7.943 ms 7.902 ms 7.793 ms
5 195.66.226.125 (195.66.226.125) 8.674 ms 8.640 ms 8.609 ms
6 209.85.252.76 (209.85.252.76) 8.075 ms 8.072 ms 8.311 ms
7 209.85.248.80 (209.85.248.80) 15.745 ms 15.749 ms 15.986 ms
8 209.85.248.79 (209.85.248.79) 18.307 ms 18.153 ms 18.079 ms
9 209.85.255.20 (209.85.255.20) 19.824 ms 20.047 ms 209.85.255.143 (209.85.255.143) 19.019 ms
10 209.85.255.110 (209.85.255.110) 27.744 ms 209.85.255.106 (209.85.255.106) 28.130 ms 28.095 ms
11 ew-in-f103.google.com (74.125.77.103) 20.087 ms 20.281 ms 20.350 ms
If I do an actual recursive lookup directly in Chicago, I get completely different results:
dig +trace www.l.google.com
; <<>> DiG 9.3.3rc2 <<>> +trace www.l.google.com
; (1 server found)
;; global options: printcmd
. 16747 IN NS K.ROOT-SERVERS.NET.
. 16747 IN NS H.ROOT-SERVERS.NET.
. 16747 IN NS F.ROOT-SERVERS.NET.
. 16747 IN NS L.ROOT-SERVERS.NET.
. 16747 IN NS E.ROOT-SERVERS.NET.
. 16747 IN NS I.ROOT-SERVERS.NET.
. 16747 IN NS A.ROOT-SERVERS.NET.
. 16747 IN NS D.ROOT-SERVERS.NET.
. 16747 IN NS G.ROOT-SERVERS.NET.
. 16747 IN NS B.ROOT-SERVERS.NET.
. 16747 IN NS M.ROOT-SERVERS.NET.
. 16747 IN NS C.ROOT-SERVERS.NET.
. 16747 IN NS J.ROOT-SERVERS.NET.
;; Received 228 bytes from 4.2.2.2#53(4.2.2.2) in 2 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 494 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 59 ms
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; Received 170 bytes from 192.5.6.30#53(a.gtld-servers.net) in 107 ms
l.google.com. 86400 IN NS b.l.google.com.
l.google.com. 86400 IN NS f.l.google.com.
l.google.com. 86400 IN NS e.l.google.com.
l.google.com. 86400 IN NS d.l.google.com.
l.google.com. 86400 IN NS c.l.google.com.
l.google.com. 86400 IN NS g.l.google.com.
l.google.com. 86400 IN NS a.l.google.com.
;; Received 258 bytes from 216.239.32.10#53(ns1.google.com) in 13 ms
www.l.google.com. 300 IN A 74.125.95.104
www.l.google.com. 300 IN A 74.125.95.147
www.l.google.com. 300 IN A 74.125.95.103
www.l.google.com. 300 IN A 74.125.95.99
;; Received 98 bytes from 74.125.45.9#53(b.l.google.com) in 32 ms
.. and a traceroute to that locally queried resolution shows a much closer response:
traceroute to 74.125.95.104 (74.125.95.104), 30 hops max, 40 byte packets
1 69.65.40.62 (69.65.40.62) 0.572 ms 0.545 ms 0.543 ms
2 so2-0-0-0.er1.Chi1.Servernap.net (69.39.239.169) 1.592 ms 1.597 ms 1.596 ms
3 ge-6-20.car1.Chicago1.Level3.net (4.79.65.49) 1.563 ms 1.567 ms 1.573 ms
4 GOOGLE-INC.car1.Chicago1.Level3.net (4.79.208.18) 1.576 ms 2.036 ms 2.035 ms
5 209.85.240.158 (209.85.240.158) 2.038 ms 2.027 ms 2.031 ms
6 72.14.232.141 (72.14.232.141) 12.496 ms 12.648 ms 12.595 ms
7 209.85.241.35 (209.85.241.35) 12.563 ms 12.549 ms 209.85.241.29 (209.85.241.29) 12.536 ms
8 209.85.240.45 (209.85.240.45) 19.477 ms 18.963 ms 72.14.239.193 (72.14.239.193) 24.902 ms
9 iw-in-f104.google.com (74.125.95.104) 12.701 ms 12.491 ms 12.964 ms
Just because Anycast routes you to the closest server doesn't mean that your queries will be locally fetched.
Central caching is great from a DNS resolution efficiency standpoint, but unfortunately it does a nice job of breaking global load balancing. |
|
|
|
odogCable Centric Vendor BiasedPremium,VIP
join:2001-08-05
Atlanta, GA
kudos:5 Reviews:
·Comcast
| Just because Anycast routes you to the closest server doesn't mean that your queries will be locally fetched.
Central caching is great from a DNS resolution efficiency standpoint, but unfortunately it does a nice job of breaking global load balancing.
I wasn't talking about DNS, just simply stating that anycast is the reasoning for the optimal routing in the case of the old gte/genuity/l3 name servers. |
|
iansltx
join:2007-02-19
Golden, CO
kudos:2 Reviews:
·Comcast
| reply to odog
Actually, SimpleCDN also uses Anycast for their CDN presence, so I've heard of the term. I assumed L3 was using Anycast on their DNS servers, as I've been on the east coast and gotten nice response times to their DNS servers there  |
|
iansltx
join:2007-02-19
Golden, CO
kudos:2 | Additionally, it would seem that, if configured properly, an anycast CDN would get around the DNS server probblem... |
|
espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2 Reviews:
·Clear Wireless
| said by iansltx:Additionally, it would seem that, if configured properly, an anycast CDN would get around the DNS server probblem... Anycast CDN is tricky because any routing change could result in termination at a different host over the term of the session. Short sessions like DNS carry low risk because it's a single request and single response packet in stateless UDP, so even if your route changes after you send your DNS request it's no big deal.
With the more common use of intelligent route reflectors to add some load distribution / performance intelligence to BGP, it's highly likely for routes to change dynamically. Since TCP is stateful if that lands you on a different cache that breaks the connection since the other cache can't pick up the session mid flow; your app needs to reset the TCP session and start again.
That's why all of the major CDN players use DNS to balance out traffic to different caches; it's the only safe way to get this done. |
|
