pptp vpn has high latency -- not routed through local tunnel server?

[sbrudenell]

i've been toying with the pptp vpn. it's a *great* idea. unfortunately, i'm experiencing enormous latency when using the vpn.

i'm on the ashland tunnel server. i get great ping times to it:

Code Select Expand

steve@aquila:~$ ping 216.66.22.2
PING 216.66.22.2 (216.66.22.2) 56(84) bytes of data.
64 bytes from 216.66.22.2: icmp_seq=1 ttl=55 time=10.0 ms
64 bytes from 216.66.22.2: icmp_seq=2 ttl=55 time=10.3 ms
64 bytes from 216.66.22.2: icmp_seq=3 ttl=55 time=13.0 ms
64 bytes from 216.66.22.2: icmp_seq=4 ttl=55 time=10.0 ms

but i ping terribly everywhere from the pptp vpn. even the private ip endpoint has huge latency:

Code Select Expand

steve@aquila:~$ ping 172.31.255.1
PING 172.31.255.1 (172.31.255.1) 56(84) bytes of data.
64 bytes from 172.31.255.1: icmp_seq=1 ttl=64 time=39.9 ms
64 bytes from 172.31.255.1: icmp_seq=2 ttl=64 time=34.8 ms
64 bytes from 172.31.255.1: icmp_seq=3 ttl=64 time=32.8 ms
64 bytes from 172.31.255.1: icmp_seq=4 ttl=64 time=35.2 ms

is this expected? i can't use the pptp vpn because of the enormous latency increase. :(

[sbrudenell]

further info:

i get great connectivity through the ashland tunnel server in general. there's barely any increase in latency at all.

traceroute to ashland tserv, normal routing:

Code Select Expand

steve@aquila:~$ traceroute 216.66.22.2
traceroute to 216.66.22.2 (216.66.22.2), 30 hops max, 60 byte packets
1  128.237.224.2 (128.237.224.2)  10.837 ms  11.747 ms  12.515 ms
2  CORE255-VL942.GW.CMU.NET (128.2.255.241)  13.585 ms  14.374 ms  15.874 ms
3  POD-I-CYH-VL987.GW.CMU.NET (128.2.255.250)  16.825 ms  17.734 ms POD-I-NH-VL987.GW.CMU.NET (128.2.255.251)  18.563 ms
4  ge-7-23.car1.Pittsburgh3.Level3.net (4.49.108.45)  19.345 ms  23.964 ms sl-st21-pit-1-1-0.sprintlink.net (144.223.26.89)  25.875 ms
5  ae-5-5.ebr1.Washington1.Level3.net (4.69.135.242)  26.809 ms  27.723 ms  28.733 ms
6  sl-bb23-rly-15-0.sprintlink.net (144.232.20.216)  29.128 ms ae-91-91.csw4.Washington1.Level3.net (4.69.134.142)  15.733 ms ae-71-71.csw2.Washington1.Level3.net (4.69.134.134)  18.047 ms
7  sl-crs1-dc-0-2-0-0.sprintlink.net (144.232.25.20)  8.356 ms sl-st22-ash-5-0.sprintlink.net (144.232.20.155)  9.088 ms ae-11-79.car1.Washington3.Level3.net (4.68.17.71)  8.568 ms
8  144.232.19.114 (144.232.19.114)  9.433 ms te3-4-10G.ar2.dca3.gblx.net (64.212.107.61)  9.840 ms 144.232.19.114 (144.232.19.114)  10.244 ms
9  te8-4-10G.ar5.DCA3.gblx.net (67.16.135.42)  10.645 ms  11.014 ms hurricane-ic-138360-ash-bb1.c.telia.net (213.248.67.118)  12.253 ms
10  HURRICANE-ELECTRIC-LLC.Te6-4.ar5.DCA3.gblx.net (207.136.166.54)  11.273 ms  11.734 ms  12.476 ms
11  tserv13.ash1.ipv6.he.net (216.66.22.2)  12.976 ms  13.309 ms  8.002 ms
ping to google, normal routing:

Code Select Expand

steve@aquila:~$ ping www.google.com
PING www.l.google.com (72.14.204.147) 56(84) bytes of data.
64 bytes from iad04s01-in-f147.1e100.net (72.14.204.147): icmp_seq=1 ttl=54 time=10.1 ms
64 bytes from iad04s01-in-f147.1e100.net (72.14.204.147): icmp_seq=2 ttl=54 time=9.21 ms
64 bytes from iad04s01-in-f147.1e100.net (72.14.204.147): icmp_seq=3 ttl=54 time=10.7 ms
64 bytes from iad04s01-in-f147.1e100.net (72.14.204.147): icmp_seq=4 ttl=54 time=9.51 ms
ping to google ipv6, over ipv6 tunnel, sans vpn:

Code Select Expand

steve@aquila:~$ ping6 ipv6.google.com
PING ipv6.google.com(iad04s01-in-x67.1e100.net) 56 data bytes
64 bytes from iad04s01-in-x67.1e100.net: icmp_seq=1 ttl=59 time=14.0 ms
64 bytes from iad04s01-in-x67.1e100.net: icmp_seq=2 ttl=59 time=16.4 ms
64 bytes from iad04s01-in-x67.1e100.net: icmp_seq=3 ttl=59 time=14.2 ms
64 bytes from iad04s01-in-x67.1e100.net: icmp_seq=4 ttl=59 time=12.7 ms

as noted above, though, everything over the pptp vpn is horribly slow. the latency seems to happen before the first hop. ipv4 and ipv6 are equally slow.

traceroute to google ipv6, over ipv6 tunnel + pptp vpn:

Code Select Expand

steve@aquila:~$ traceroute6 www.google.com
traceroute to www.google.com (2001:4860:8009::93), 30 hops max, 80 byte packets
1  sbrudenell-2.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:7ef::1)  39.538 ms  39.420 ms  39.360 ms
2  gige-g4-12.core1.ash1.he.net (2001:470:0:90::1)  45.824 ms  57.872 ms  57.819 ms
3  pr61.iad07.net.google.com (2001:504:0:2:0:1:5169:1)  57.765 ms  57.709 ms  57.653 ms
4  2001:4860::1:0:5dc (2001:4860::1:0:5dc)  38.963 ms 2001:4860::1:0:9ff (2001:4860::1:0:9ff)  57.540 ms 2001:4860::1:0:5dc (2001:4860::1:0:5dc)  38.853 ms 5  2001:4860::1:0:489 (2001:4860::1:0:489)  57.430 ms 2001:4860::1:0:5db (2001:4860::1:0:5db)  138.288 ms 2001:4860::1:0:489 (2001:4860::1:0:489)  57.313 ms
6  2001:4860::2:0:ba (2001:4860::2:0:ba)  57.260 ms  39.679 ms  39.595 ms
7  2001:4860:0:1::bf (2001:4860:0:1::bf)  46.589 ms 2001:4860:0:1::c1 (2001:4860:0:1::c1)  58.450 ms 2001:4860:0:1::bf (2001:4860:0:1::bf)  46.479 ms
8  yw-in-x93.1e100.net (2001:4860:8009::93)  47.867 ms  47.779 ms  47.719 ms

on investigating, i see that my normal routing to the public ip for the vpn is strange.

traceroute to the public ip for my vpn, vpn disconnected, normal routing:

Code Select Expand

steve@aquila:~$ traceroute 184.104.103.52
traceroute to 184.104.103.52 (184.104.103.52), 30 hops max, 60 byte packets
1  128.237.224.2 (128.237.224.2)  3.599 ms  3.664 ms  3.718 ms
2  CORE255-VL942.GW.CMU.NET (128.2.255.241)  3.826 ms  3.879 ms  3.991 ms
3  POD-I-CYH-VL987.GW.CMU.NET (128.2.255.250)  5.474 ms POD-I-NH-VL987.GW.CMU.NET (128.2.255.251)  4.115 ms  4.275 ms
4  sl-st21-pit-1-1-0.sprintlink.net (144.223.26.89)  6.776 ms ge-7-23.car1.Pittsburgh3.Level3.net (4.49.108.45)  11.147 ms sl-st21-pit-1-1-0.sprintlink.net (144.223.26.89)  7.492 ms
5  sl-crs2-rly-0-5-0-0.sprintlink.net (144.232.9.98)  9.851 ms ae-5-5.ebr1.Washington1.Level3.net (4.69.135.242)  9.382 ms  9.405 ms
6  ae-91-91.csw4.Washington1.Level3.net (4.69.134.142)  9.514 ms sl-crs2-dc-0-12-2-0.sprintlink.net (144.232.19.221)  31.147 ms sl-crs2-dc-0-6-0-3.sprintlink.net (144.232.9.214)  7.446 ms
7  sl-st21-ash-10-0-0.sprintlink.net (144.232.20.148)  9.351 ms ae-31-99.car1.Washington3.Level3.net (4.68.17.199)  8.167 ms sl-st21-ash-10-0-0.sprintlink.net (144.232.20.148)  9.626 ms
8  144.232.18.66 (144.232.18.66)  9.811 ms  10.567 ms sjo-bb1-link.telia.net (80.91.248.188)  77.725 ms
9  Hurrican-Electric-LLC.TenGigabitEthernet1-4.ar2.SJC2.gblx.net (64.214.174.246)  72.496 ms  72.567 ms  85.511 ms
10  10gigabitethernet3-2.core1.pao1.he.net (72.52.92.69)  73.375 ms  76.905 ms  77.113 ms
11  10gigabitethernet2-4.core1.ash1.he.net (72.52.92.30)  86.950 ms  87.156 ms  96.070 ms
12  sbrudenell-2.tserv13.ash1.dyn.he.net (184.104.103.52)  81.394 ms  81.111 ms  82.109 ms

it's confusing that i'm apparently routed to the bay area, then back to ashland, for this ip.

i don't believe this can be a problem with my local routing, because i tried this trace from a host on verizon fios, and was also routed through the bay area. bad local routing also doesn't explain my first hop over the vpn having huge latency.

[patrickdk]

Well there is the issue: sjo-bb1-link.telia.net :)

A europian carrier.

Seems like sprint is sometimes picking to use it, based on who knows routing rules they are using. HE might be able to affect this some with their bgp advertizements.

[sbrudenell]

the telia.net hop sure is strange, but i don't see it very consistently. my traces usually look more like this:

Code Select Expand

traceroute to 184.104.103.52 (184.104.103.52), 30 hops max, 60 byte packets
1  128.237.224.2 (128.237.224.2)  5.213 ms * *
2  CORE255-VL942.GW.CMU.NET (128.2.255.241)  8.878 ms * *
3  POD-I-NH-VL987.GW.CMU.NET (128.2.255.251)  13.989 ms * POD-I-CYH-VL987.GW.CMU.NET (128.2.255.250)  12.574 ms
4  ge-7-23.car1.Pittsburgh3.Level3.net (4.49.108.45)  23.431 ms sl-st21-pit-1-1-0.sprintlink.net (144.223.26.89)  16.213 ms ge-7-23.car1.Pittsburgh3.Level3.net (4.49.108.45)  23.439 ms
5  ae-5-5.ebr1.Washington1.Level3.net (4.69.135.242)  17.187 ms sl-crs2-rly-0-5-0-0.sprintlink.net (144.232.9.98)  18.916 ms  19.916 ms
6  ae-81-81.csw3.Washington1.Level3.net (4.69.134.138)  20.623 ms ae-91-91.csw4.Washington1.Level3.net (4.69.134.142)  9.988 ms sl-crs2-dc-0-12-2-0.sprintlink.net (144.232.19.221)  10.848 ms
7  ae-21-69.car1.Washington3.Level3.net (4.68.17.7)  8.801 ms ae-31-99.car1.Washington3.Level3.net (4.68.17.199)  8.494 ms sl-st21-ash-10-0-0.sprintlink.net (144.232.20.148)  11.591 ms
8  144.232.18.66 (144.232.18.66)  11.768 ms glbx-level3.washington3.level3.net (4.68.110.90)  10.768 ms  13.783 ms
9  Hurrican-Electric-LLC.TenGigabitEthernet1-4.ar2.SJC2.gblx.net (64.214.174.246)  71.772 ms  81.648 ms  81.808 ms
10  10gigabitethernet3-2.core1.pao1.he.net (72.52.92.69)  83.625 ms  82.776 ms  83.594 ms
11  10gigabitethernet2-4.core1.ash1.he.net (72.52.92.30)  90.776 ms  90.011 ms  88.454 ms
12  sbrudenell-2.tserv13.ash1.dyn.he.net (184.104.103.52)  82.905 ms  82.686 ms  91.164 ms

there's no hint of the netherlands there.

and again, even european routing doesn't explain (to me, anyway) why my ping to the first hop over the vpn is 30ms more than my ping to the vpn server itself. i think that should be entirely within HE.

[brad]

Well there is the issue: sjo-bb1-link.telia.net :)

A europian carrier.

Well Telia is a European carrier. TeliaSonera International Carrier, their wholesale division, has a number of
POPs in the U.S as well as Asian POPs. The POP you have mentioned above is in San Jose. One of the other traceroutes also shows a TeliaSonera POP in Ashburn. TeliaSonera is one of HE's transit providers as well as Global Crossing.