how-to block ads
|
|
Uniqs:
492 |
Share Topic
 |
 |
|
|
|
Reviews:
 ·Google Voice
·Junction Networks
·Callcentric
 ·T-Mobile US
 ·AT&T U-Verse
| [IPv6] [latency] [BayArea] Local IPv6 around San Jose?I'm on AT&T's IPv6 network in San Jose, CA, and I'm trying to find the best edge nodes latency-wise. Here's what I have so far, California-wise.
% alias traceroute6 traceroute6 -w2 -l
% traceroute6 ipv6.akamai.com
traceroute6 to a152.i6g1.akamai.net (2600:5:3700:2::c703:730b) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.863 ms 1.149 ms 1.304 ms
2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 8.013 ms 3.031 ms 3.605 ms
3 2001:1890:1fff:404:192:205:35:18 (2001:1890:1fff:404:192:205:35:18) 5.989 ms 21.109 ms *
4 2600:5:3700:2::c703:730b (2600:5:3700:2::c703:730b) 5.248 ms 7.884 ms 5.317 ms
% alias postcmd date
% traceroute6 ipv6.akamai.com
Fri 17 Feb 2012 12:13:45 PST
traceroute6 to a152.i6g1.akamai.net (2001:559:0:301::6011:6d48) from 2602:306:37cY:YYY0::1 , 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.701 ms 1.306 ms 1.336 ms
2 sfcca03jt.ip.att.net (2001:1890:ff:ffff:12:122:126:243) 3.134 ms 2.941 ms 3.006 ms
3 2001:1890:1fff:400:192:205:37:2 (2001:1890:1fff:400:192:205:37:2) 9.998 ms 7.029 ms 7.734 ms
4 pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1) 10.499 ms 12.967 ms 10.206 ms
5 pos-0-4-0-0-pe01.529bryant.ca.ibone.comcast.net (2001:558:0:f5e4::2) 9.635 ms 8.965 ms 8.941 ms
6 2001:559::16 (2001:559::16) 11.532 ms 8.532 ms 8.35 ms
7 2001:559:0:301::6011:6d48 (2001:559:0:301::6011:6d48) 8.428 ms 8.403 ms 8.437 ms
% traceroute6 www.limelight.com
Fri 17 Feb 2012 12:14:09 PST
traceroute6 to llnw.vo.llnwd.net (2607:f4e8:110:104:230:48ff:fe87:3054) from 2602:306:37cY :YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.613 ms 1.336 ms 1.281 ms
2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 2.917 ms 3.037 ms 2.898 ms
3 2001:450:2008:100::109 (2001:450:2008:100::109) 70.089 ms 70.23 ms 70.255 ms
4 2001:450:2002:2c6::2 (2001:450:2002:2c6::2) 16.898 ms 24.493 ms 13.562 ms
5 ve4.fr3.snv1.ipv6.llnw.net (2607:f4e8:1:a4::2) 14.659 ms 20.964 ms 14.185 ms
6 cds205.sjc.llnw.net (2607:f4e8:110:104:230:48ff:fe87:3054) 15.343 ms 15.902 ms 16.2 78 ms
% traceroute6 ipv6.google.com
Fri 17 Feb 2012 12:14:35 PST
traceroute6 to ipv6.l.google.com (2001:4860:4001:800::1011) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.749 ms 1.173 ms 1.346 ms
2 sj2ca404me3.ip.att.net (2001:1890:ff:ffff:12:122:119:192) 4.048 ms 3.999 ms 4.059 m s
3 2001:1890:c00:8c02::1116:e9cb (2001:1890:c00:8c02::1116:e9cb) 50.029 ms 48.965 ms 4 7.51 ms
4 2001:4860::1:0:21 (2001:4860::1:0:21) 5.225 ms 5.96 ms 5.481 ms
5 2001:4860:0:1::1ab (2001:4860:0:1::1ab) 5.381 ms 5.204 ms 5.305 ms
6 2001:4860:4001:800::17 (2001:4860:4001:800::17) 54.298 ms 53.502 ms 53.744 ms
% traceroute6 ns2.he.net
Fri 17 Feb 2012 12:15:46 PST
traceroute6 to ns2.he.net (2001:470:200::2) from 2602:306:37cY:YYY0::1, 30 hops max, 12 by te packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.601 ms 1.266 ms 1.283 ms
2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 13.73 ms 13.632 ms 13.996 ms
3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 18.977 ms 13.617 ms 13.7 08 ms
4 10gigabitethernet7-3.core1.sjc2.he.net (2001:470:0:16a::1) 22.056 ms 24.109 ms 24.9 28 ms
5 ns2.he.net (2001:470:200::2) 22.112 ms 22.085 ms 21.968 ms
% traceroute6 www.ixsystems.com
Fri 17 Feb 2012 12:16:38 PST
traceroute6 to web.ixsystems.com (2607:fca8:2636:8001::4) from 2602:306:37cY:YYY0::1, 30 h ops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.629 ms 1.233 ms 1.183 ms
2 la2ca02jt.ip.att.net (2001:1890:ff:ffff:12:122:127:43) 14.812 ms 13.473 ms 13.863 m s
3 10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::1) 14.281 ms 15.176 ms 13.6 82 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 13.531 ms 18.466 ms 20.74 4 ms
5 2607:fca8:1530::1 (2607:fca8:1530::1) 13.688 ms 13.865 ms 13.782 ms
6 2607:fca8:2636:8001::4 (2607:fca8:2636:8001::4) 14.136 ms 14.481 ms 14.672 ms
% traceroute6 www.arpnetworks.com
Fri 17 Feb 2012 12:17:02 PST
traceroute6 to www.arpnetworks.com (2607:f2f8:0:102::3) from 2602:306:37cY:YYY0::1, 30 hop s max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.74 ms 1.222 ms 1.182 ms
2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 113.136 ms 3.134 ms 2.922 m s
3 2001:450:2008:100::109 (2001:450:2008:100::109) 150.088 ms 2001:450:2008:100::c5 (200 1:450:2008:100::c5) 69.797 ms 70.066 ms
4 * * *
5 2607:f2f8:100:105::1 (2607:f2f8:100:105::1) 14.123 ms 14.058 ms 14.096 ms
6 www.arpnetworks.com (2607:f2f8:0:102::3) 14.616 ms 14.429 ms 14.47 ms
% traceroute6 obsd.isc.org
Fri 17 Feb 2012 12:20:22 PST
traceroute6 to obsd.isc.org (2001:4f8:3:36::217) from 2602:306:37cY:YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.753 ms 1.213 ms 1.905 ms
2 sfcca01jt.ip.att.net (2001:1890:ff:ffff:12:122:126:241) 2.957 ms 4.544 ms 3.373 ms
3 2001:1890:1fff:40d:192:205:33:50 (2001:1890:1fff:40d:192:205:33:50) 4.895 ms * 5.069 ms
4 chi-bb1-v6.telia.net (2001:2000:3018:2c::1) 55.734 ms 55.583 ms 55.652 ms
5 isc-ic-117366-chi-bb1.c.telia.net (2001:2000:3080:138::2) 55.852 ms 56.083 ms 56.07 8 ms
6 int-0-0-1-8.r1.pao1.isc.org (2001:4f8:0:1::4a:1) 108.838 ms 108.864 ms 110.633 ms
7 int-0-1-0-0.r1.sql1.isc.org (2001:4f8:1b:1::8:2) 112.205 ms 108.617 ms 109.507 ms
8 2001:4f8:3:36::217 (2001:4f8:3:36::217) 108.234 ms 107.538 ms 108.512 ms
So far, the now-disappeared DNS resolution of ipv6.akamai.com over at Sprint seemed to have had the best latency earlier this morning, of only 5.3ms.
IPv4-wise, I can still get 3.7ms to some CDN host at nlayer.net (see »[FTTH] 4ms+ ping to anywhere outside of the AT&T border and the traceroute below), so, I'm thinking that something around 4ms should be entirely possible with IPv6, too.
% traceroute -I 69.22.162.122
Fri 17 Feb 2012 12:41:33 PST
traceroute to 69.22.162.122 (69.22.162.122), 32 hops max, 60 byte packets
5 12.83.39.145 (12.83.39.145) 16.198 ms 2.141 ms 1.800 ms
6 ppp-151-164-52-233.rcsntx.swbell.net (151.164.52.233) 99.646 ms 207.202 ms 5.913 ms
7 asn4436-nlayer.pxpaca.sbcglobal.net (151.164.46.70) 5.041 ms 4.636 ms 4.421 ms
8 69.22.162.122 (69.22.162.122) 3.802 ms 3.792 ms 3.710 ms
Any ideas what other IPv6 hosts are in the Bay Area that could have good latency with AT&T's IPv6 network?
| | |
|
| ConstantineM, whats your ipv6 latency look like to my server? box.houkouonchi.jp
--
150/75 mbit Verizon FiOS connection FTW! | |
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| % traceroute6 box.houkouonchi.jp
Sat 18 Feb 2012 11:24:57 PST
traceroute6 to box.houkouonchi.jp (2607:f298:1:100:feed:face:beef:d00d) from 2602:306:37cY :YYY0::1, 30 hops max, 12 byte packets
1 2602:300:c533:1510::5 (2602:300:c533:1510::5) 1.623 ms 1.284 ms 1.28 ms
2 sfcca02jt.ip.att.net (2001:1890:ff:ffff:12:122:126:242) 2.992 ms 3.019 ms 3.091 ms
3 2001:550:3::2a9 (2001:550:3::2a9) 4.963 ms 2001:550:3::2ad (2001:550:3::2ad) 9.923 m s *
4 2001:550:2:9::3:2 (2001:550:2:9::3:2) 16.481 ms 16.241 ms 16.218 ms
5 2607:f298:0:111::2 (2607:f298:0:111::2) 16.237 ms 16.121 ms *
6 ip-2607-F298-0001-0100-FEED-FACE-BEEF-D00D.dreamhost.com (2607:f298:1:100:feed:face:beef:d00d) 16.177 ms 16.232 ms 16.395 ms
Kinda slow, IMHO. :-p The arpnetworks.com network (over in LA somewhere) gives only 14ms via IPv6, which is faster than their IPv4 (16ms just as your IPv6). :-) Still, that's only 2ms extra, pretty good, considering how isc.org over here in Bay Area goes all the way through Chicago with AT&T IPv6. :-)
P.S. cogentco.com sucks sh1t. Try `dig +trace -x 2001:550:2:9::3:2`, it's terrible how slow traceroute6 on hop 4 is! Feel free to try a few times. ;-)
| |
Reviews:
·Verizon FiOS
 ·Charter
·AT&T U-Verse
 ·DSL EXTREME
| Here is what I get to he.net in northcal (from LA):
traceroute to he.net (2001:470:0:76::2), 30 hops max, 80 byte packets
1 ip-2607-f298-1-100-0-0-0-1.dreamhost.com (2607:f298:1:100::1) 41.548 ms 8.417 ms 0.502 ms
2 2607:f298:0:111::1 (2607:f298:0:111::1) 0.957 ms 0.348 ms 0.501 ms
3 2001:504:13::1a (2001:504:13::1a) 0.389 ms 4.193 ms 0.525 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 0.459 ms 0.443 ms 0.331 ms
5 10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1) 8.533 ms 8.536 ms 9.067 ms
6 gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1) 8.599 ms 8.549 ms 8.543 ms
7 he.net (2001:470:0:76::2) 8.870 ms 8.870 ms 8.901 ms
It takes 3 seconds to run that dig command. Pretty sure that IP is our cogent ipv6 IP on our border router but we don't control DNS (which is what I believe you are saying is slow)?
--
150/75 mbit Verizon FiOS connection FTW! | |
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| Why IPv6 latency between Tier 1 networks is so bad? said by houkouonchi:It takes 3 seconds to run that dig command. Pretty sure that IP is our cogent ipv6 IP on our border router but we don't control DNS (which is what I believe you are saying is slow)? Yes; however, `dig -4 @dnsr1.sbcglobal.net -x 2001:550:2:9::3:2` takes 10 seconds, always 10 seconds. :-)
No wonder you get great latency to HE in Fremont, peering with them over in LA! That's probably the same latency on both IPv4 and IPv6, right? However, what'd be more interesting is your Cogentco transit latency. :-p
BTW, why are you buying IPv6 transit from Cogent instead of HE? Looks like you'd lose 2ms with Bay Area AT&T if you go HE. :-p
...
BTW, looking at my traceroute6 from the original message of this thread, I'm honestly surprised how come all these Tier 1 backbones have such horrible IPv6 latencies for traffic that doesn't even leave the Bay Area, supposedly. So far, AT&T ↔ HE in LA is the single best traceroute6 I have, comparatively; Sprint in the Bay Area seems to be second best.
How come Comcast ↔ AT&T latency is so bad (8.4ms)? What do they do with the traffic to make it so bad? Why is AT&T ↔ Level3 ↔ Limelight is even worse (15ms)? Seriously where do those extra 10ms go into, where the final node is still claimed to be in San Jose? Do they peer like in a forgotten CO in Fresno or something? Or is it the reverse route that goes through something like LA? | |
Reviews:
·Verizon FiOS
·Charter
·AT&T U-Verse
·DSL EXTREME
| Probably something weird going on the reverse route. causing that much higher latency. Actually ipv4 latency is a bit worse:
traceroute to he.net (216.218.186.2), 30 hops max, 46 byte packets
1 ip-66-33-193-1 (66.33.193.1) 23.413 ms 0.557 ms 0.342 ms
2 ip-66-33-201-113 (66.33.201.113) 0.313 ms 0.315 ms 0.291 ms
3 he.net.coresite.com (206.223.143.122) 2.042 ms 6.158 ms 0.563 ms
4 10gigabitethernet7-3.core1.sjc2.he.net (184.105.213.6) 16.199 ms 8.816 ms 16.426 ms
5 10gigabitethernet1-1.core1.fmt1.he.net (72.52.92.109) 14.255 ms 21.690 ms 9.670 ms
6 he.net (216.218.186.2) 9.307 ms 9.242 ms 9.274 ms
Also.. You typically don't buy 'ipv6' transit. You buy transit (period) and its usually both ipv4/ipv6. Also ipv6 probably accounts for 0.01% (or lower) of our entire network usage. I seem to recall HE was actually nice enough to offer transit service for ipv6 only via our peering link but I don't think we actually ever did it.
I think we have ipv6 over all our providers except maybe above.net (including comcast).
Also constantinem why would you be using AT&T's DNS servers? I never use my ISP's DNS servers for anything.
Getting traceroute to web.ixsystems.com (2607:fca8:2636:8001::4) from 2607:f298:1:100:feed:face:beef:d00d, 30 hops max, 24 byte packets
1 ip-2607-f298-1-100-0-0-0-1.dreamhost.com (2607:f298:1:100::1) 4.886 ms * 0.565 ms
2 2607:f298:0:111::1 (2607:f298:0:111::1) 0.468 ms 5.122 ms 0.826 ms
3 2001:504:13::1a (2001:504:13::1a) 0.386 ms 0.342 ms 0.501 ms
4 10gigabitethernet2-1.core1.lax1.he.net (2001:470:0:72::1) 0.406 ms 0.422 ms 0.525 ms
5 2607:fca8:1530::1 (2607:fca8:1530::1) 0.462 ms 0.562 ms 0.457 ms
6 2607:fca8:2636:8001::4 (2607:fca8:2636:8001::4) 0.732 ms 0.898 ms 0.915 ms
--
150/75 mbit Verizon FiOS connection FTW! | |
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| local DNS resolver doesn't play nice with Akamai said by houkouonchi:Also constantinem why would you be using AT&T's DNS servers? I never use my ISP's DNS servers for anything. Because they're mostly compliant, without any spam records, and are only 3ms away? 
Also, I've noticed that DNS-based CDNs are still somehow broken when using a local resolver here (which, I know, doesn't make much sense). Right now, I tried doing a `dig +trace` for www.google.com and www.akamai.com. Whereas www.google.com got resolved to the same local IPs as the resolution from dnsr1.sbcglobal.net, www.akamai.com local resolution (had to manually re-run dig three times for that, BTW) was for IP-addresses in Dallas, whereas dnsr1 did provide Bay Area IP addresses.
All web-sites do report my IP-addresses as some towns around here in the Bay Area; perhaps Akamai uses their own database of resolvers, and gives out Dallas for any resolvers with unknown addresses? Or perhaps they use the data from ARIN for infrequent resolvers, which is in fact Texas for all of my IP addresses?
I have had the same IP addresses over here for almost two years (and I do recall these DNS CDN-related problems with a local resolver back from the beginning). | |
|
