I am on Earthlink (thus effectively RR) in North Carolina, so one would think that ASH or NYC (maybe even MIA) would be good choices. Unfortunately no matter what tunnel server I trace to, I get hauled across RR's backbone to a peering point in San Jose. Someone here in the forums was having a similar problem out of DAL about a year ago, but I don't think anything ever came of it. Knowing full well that they won't listen to a lowly customer like me about things like peering, is there some other avenue to improve my route?
Some traces for reference:
kjotte@polaris:~$ tracepath tserv7.ash1.ipv6.he.net
1: polaris-wifi.nivex.lan (172.31.3.23) 0.221ms pmtu 1500
1: peregrine.nivex.lan (172.31.3.254) 2.143ms
1: peregrine.nivex.lan (172.31.3.254) 1.855ms
2: user-0c2h381.cable.mindspring.com (24.40.141.1) 16.944ms
3: gig0-1-1.rlghnca-rtr2.nc.rr.com (66.26.33.157) 34.706ms
4: xe-4-0-1.chrlncpop-rtr1.southeast.rr.com (24.93.64.6) 45.202ms asymm 5
5: ae-3-0.cr0.atl20.tbone.rr.com (66.109.6.82) 41.377ms asymm 6
6: ae-3-0.cr0.dfw10.tbone.rr.com (66.109.6.36) 45.044ms
7: ae-0-0.cr0.hou30.tbone.rr.com (66.109.6.38) 56.993ms
8: ae-3-0.cr0.lax30.tbone.rr.com (66.109.6.0) 90.059ms
9: ae-0-0.cr0.lax00.tbone.rr.com (66.109.6.4) 83.591ms
10: ae-3-0.cr0.sjc30.tbone.rr.com (66.109.6.6) 91.761ms
11: ae-1-0.pr0.sjc10.tbone.rr.com (66.109.6.137) 135.536ms asymm 12
12: gige-g5-6.core1.sjc2.he.net (216.218.135.225) 91.988ms asymm 13
13: 10gigabitethernet3-2.core1.pao1.he.net (72.52.92.69) 92.059ms asymm 12
14: 10gigabitethernet2-4.core1.ash1.he.net (72.52.92.30) 104.432ms asymm 10
15: ash.ipv6.he.net (216.218.229.118) 106.899ms reached
Resume: pmtu 1500 hops 15 back 245
kjotte@polaris:~$ tracepath tserv4.nyc4.ipv6.he.net
1: polaris-wifi.nivex.lan (172.31.3.23) 0.176ms pmtu 1500
1: peregrine.nivex.lan (172.31.3.254) 1.727ms
1: peregrine.nivex.lan (172.31.3.254) 1.806ms
2: user-0c2h381.cable.mindspring.com (24.40.141.1) 16.393ms
3: gig0-1-1.rlghnca-rtr2.nc.rr.com (66.26.33.157) 38.942ms
4: ge-5-3-0.chrlncpop-rtr1.southeast.rr.com (24.93.64.2) 43.296ms asymm 5
5: ae-3-0.cr0.atl20.tbone.rr.com (66.109.6.82) 72.009ms asymm 6
6: ae-3-0.cr0.dfw10.tbone.rr.com (66.109.6.36) 56.382ms
7: ae-0-0.cr0.hou30.tbone.rr.com (66.109.6.38) 52.791ms
8: ae-3-0.cr0.lax30.tbone.rr.com (66.109.6.0) 81.374ms
9: ae-0-0.cr0.lax00.tbone.rr.com (66.109.6.4) 84.013ms
10: ae-3-0.cr0.sjc30.tbone.rr.com (66.109.6.6) 107.589ms
11: ae-1-0.pr0.sjc10.tbone.rr.com (66.109.6.137) 91.693ms asymm 12
12: gige-g5-15.core1.sjc2.he.net (216.218.135.229) 105.623ms asymm 13
13: 10gigabitethernet1-3.core1.nyc4.he.net (72.52.92.26) 108.806ms
14: no reply
15: no reply
^C
I've got the same problem in Kansas City. Road Runner appears to be routing everything destined for HE to San Jose for some reason.
I don't know what we can do to get it fixed since it looks like it's Road Runner's routing that has a problem. I imagine all Road Runner customers are getting terrible routes to their tunnel servers because of this, unless you're lucky enough to be near San Jose.
4: RDC-24-94-161-34.kc.rr.com (24.94.161.34) 29.557ms asymm 5
5: ae-5-0.cr0.chi30.tbone.rr.com (66.109.6.112) 32.310ms asymm 6
6: ae-0-0.cr0.chi10.tbone.rr.com (66.109.6.20) 29.395ms asymm 7 <- Passing through Chicago!
7: ae-3-0.cr0.sjc10.tbone.rr.com (66.109.6.14) 80.890ms asymm 8
8: ae-0-0.pr0.sjc10.tbone.rr.com (66.109.6.141) 82.254ms asymm 10
9: gige-g5-15.core1.sjc2.he.net (216.218.135.229) 95.587ms asymm 14
10: 10gigabitethernet1-1.core1.chi1.he.net (72.52.92.74) 84.965ms asymm 9
11: tserv9.chi1.ipv6.he.net (209.51.181.2) 85.874ms reached
Traceroute to one hop before the Chicago HE core:
Loss% Snt Last Avg Best Wrst StDev
4. CPE-69-76-62-253.kc.res.rr.c 0.0% 10 19.8 21.4 19.8 26.1 2.0
5. ae-4-0.cr0.chi10.tbone.rr.co 0.0% 10 20.5 21.6 19.9 29.3 2.9
6. ae-0-0.pr0.chi10.tbone.rr.co 0.0% 10 25.0 29.5 24.1 55.1 9.5
7. chi-bb1-link.telia.net 0.0% 10 20.3 26.4 18.7 57.1 11.5
Traceroute to the Chicago HE core:
Loss% Snt Last Avg Best Wrst StDev
4. CPE-69-76-62-253.kc.res.rr.c 0.0% 10 39.5 24.1 19.5 39.5 6.0
5. ae-4-0.cr0.chi10.tbone.rr.co 0.0% 10 20.4 21.5 19.3 26.5 2.1
6. ae-3-0.cr0.sjc10.tbone.rr.co 0.0% 10 75.3 80.6 75.3 92.4 6.3
7. ae-0-0.pr0.sjc10.tbone.rr.co 0.0% 10 79.7 83.1 77.1 117.1 12.0
8. gige-g5-6.core1.sjc2.he.net 0.0% 10 86.3 87.1 84.8 90.0 1.7
9. core1.chi1.he.net 0.0% 10 77.2 84.4 77.2 100.0 7.6
Traceroute from Chicago HE core to me:
1 5 ms <1 ms <1 ms chi-bb1-link.telia.net (213.248.104.213)
2 <1 ms <1 ms <1 ms timewarner-ic-130992-chi-bb1.c.telia.net (213.248.76.98)
3 <1 ms <1 ms 1 ms ae-1-0.cr0.chi30.tbone.rr.com (66.109.6.154)
4 <1 ms <1 ms <1 ms ae-15.chcgill3-rtr1.kc.rr.com (66.109.6.113)
5 20 ms <1 ms 23 ms RDC-24-94-161-33.kc.rr.com (24.94.161.33)
Oh joy, the routing is asymmetric. I just traced from ASH back to me:
core1.ash1.he.net> traceroute 24.40.141.158 numeric
1 <1 ms <1 ms <1 ms ash-bb1-link.telia.net (213.248.98.93)
2 <1 ms <1 ms <1 ms timewarner-ic-130990-ash-bb1.c.telia.net (213.248.89.194)
3 <1 ms <1 ms <1 ms ae-2-0.cr0.dca10.tbone.rr.com (66.109.6.168)
4 16 ms 16 ms 16 ms ae-1-0.cr1.atl20.tbone.rr.com (66.109.6.32)
5 17 ms 16 ms 17 ms ae-0-0.cr0.atl20.tbone.rr.com (66.109.6.34)
6 21 ms 21 ms 21 ms 66.109.6.83
7 26 ms 26 ms 26 ms gig4-0-0.rlghnca-rtr2.southeast.rr.com (24.93.64.177)
8 28 ms 27 ms 28 ms gig16-1.rlghnce-ar42.nc.rr.com (66.26.33.158)
9 45 ms 48 ms 50 ms user-0c2h3cu.cable.mindspring.com (24.40.141.158)
That's a route I could live with.
Quote from: kjotte on December 26, 2009, 08:26:40 PM
Oh joy, the routing is asymmetric.
This is the Internet. That has been the norm for a long time.
As the routing is assymetric, the "problem" lies with RoadRunner and their importing of routes external to their network into their own routers at the BGP level. Apparently, they're only importing a route to HE from their peering with HE in California and not accepting routes to HE via other carriers (even when those routes are shorter).
So I guess the question is: Do I go ahead and redo my tunnel for Ashburn, despite the recommendation of the tunnel creation page, knowing that my return packets will be taking a much shorter path?
Quote from: kjotte on December 30, 2009, 09:49:38 PM
So I guess the question is: Do I go ahead and redo my tunnel for Ashburn, despite the recommendation of the tunnel creation page, knowing that my return packets will be taking a much shorter path?
You can have tunnels wherever you like. The recommendation is just that, a recommendation. If having the tunnel to the Ashburn POP results in better latency with your connection then by all means setup a tunnel to that POP.