Hi,
I am getting really slow speeds of 1 to 2kb/s through my HE tunnel.
If I try the same website but force IPv4 I get 30 to 50Kb/s (so yes it's not a fast website in general). I have also noticed general slow responses in web pages using IPv6 etc.
My link is only 2.5Mbps (In the Philippines), and generally I average 300 to 360Kb/s download speeds across IPv4
I have attempted multiple speed tests for IPv6 from various sites and it fails to complete
Here's one example:
(http://img2.ipv6-test.com/speedtest/result/2012/06/04/0197c7f5fa08ba18e625efaca4cf4b68.png) (http://ipv6-test.com)
My tunnel settings are:
interface Tunnel0
description IPv6 uplink to Hurricane Electric
no ip address
ipv6 address 2001:470:C:550::2/64
ipv6 enable
ipv6 traffic-filter V6INBOUND in
ipv6 mtu 1280
ipv6 nd prefix 2001:470:C:550::/64 no-advertise
ipv6 inspect V6-INSPECT out
ipv6 virtual-reassembly
tunnel source BVI1
tunnel destination 66.220.18.42
tunnel mode ipv6ip
The first thing I noticed was a high latency to your tunnel.traceroute to 2001:470:C:550::2 (2001:470:C:550::2), 30 hops max, 80 byte packets
1 2001:470:1f0b:1da2:635a:c32:ae34:df91 0.135 ms 0.053 ms 0.048 ms
2 2001:470:1f0a:1da2::1 50.269 ms 46.264 ms 44.411 ms
3 2001:470:0:69::1 36.055 ms 42.747 ms 36.564 ms
4 2001:470:0:1d2::1 52.996 ms 61.673 ms 55.273 ms
5 2001:470:0:128::1 123.279 ms 122.099 ms 123.116 ms
6 2001:470:0:10e::1 190.705 ms 180.847 ms 190.861 ms
7 2001:470:20::2 187.857 ms 187.060 ms 185.203 ms
8 2001:470:c:550::2 376.000 ms 385.439 ms 366.541 ms
The 180ms roundtrip from me to your tunnel server is not unusual for a transatlantic link. (as a rule of thumb each 100km adds 1ms to the roundtrip). The additional 180ms between the tunnel server and your gateway indicates that you picked a tunnel server far away from where you are located. But since you are in the Philippines, HE might not have a tunnel server close to you.
I can't say whether this amount of latency is enough to drive your throughput that much down. If you ping the IPv4 and IPv6 addresses of that test server, what roundtrips do you see?
I noticed the same thing too for a while today. The time in my Bash prompt is EDT and regulated by NTP (so SHOULD be accurate).
2 12:36:45 root@rootin:~ 0# ping -n 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=2 ttl=52 time=149 ms
64 bytes from 216.66.22.2: icmp_seq=13 ttl=52 time=154 ms
64 bytes from 216.66.22.2: icmp_seq=16 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=17 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=20 ttl=52 time=160 ms
64 bytes from 216.66.22.2: icmp_seq=23 ttl=52 time=151 ms
64 bytes from 216.66.22.2: icmp_seq=24 ttl=52 time=157 ms
64 bytes from 216.66.22.2: icmp_seq=26 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=27 ttl=52 time=152 ms
64 bytes from 216.66.22.2: icmp_seq=28 ttl=52 time=158 ms
64 bytes from 216.66.22.2: icmp_seq=30 ttl=52 time=152 ms
64 bytes from 216.66.22.2: icmp_seq=34 ttl=52 time=161 ms
64 bytes from 216.66.22.2: icmp_seq=35 ttl=52 time=190 ms
64 bytes from 216.66.22.2: icmp_seq=36 ttl=52 time=154 ms
64 bytes from 216.66.22.2: icmp_seq=39 ttl=52 time=168 ms
64 bytes from 216.66.22.2: icmp_seq=41 ttl=52 time=148 ms
64 bytes from 216.66.22.2: icmp_seq=42 ttl=52 time=157 ms
64 bytes from 216.66.22.2: icmp_seq=46 ttl=52 time=159 ms
64 bytes from 216.66.22.2: icmp_seq=48 ttl=52 time=145 ms
64 bytes from 216.66.22.2: icmp_seq=49 ttl=52 time=155 ms
64 bytes from 216.66.22.2: icmp_seq=50 ttl=52 time=157 ms
64 bytes from 216.66.22.2: icmp_seq=51 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=57 ttl=52 time=174 ms
64 bytes from 216.66.22.2: icmp_seq=58 ttl=52 time=149 ms
64 bytes from 216.66.22.2: icmp_seq=60 ttl=52 time=151 ms
64 bytes from 216.66.22.2: icmp_seq=63 ttl=52 time=158 ms
64 bytes from 216.66.22.2: icmp_seq=65 ttl=52 time=161 ms
64 bytes from 216.66.22.2: icmp_seq=67 ttl=52 time=168 ms
64 bytes from 216.66.22.2: icmp_seq=68 ttl=52 time=152 ms
64 bytes from 216.66.22.2: icmp_seq=69 ttl=52 time=159 ms
64 bytes from 216.66.22.2: icmp_seq=71 ttl=52 time=151 ms
64 bytes from 216.66.22.2: icmp_seq=73 ttl=52 time=172 ms
64 bytes from 216.66.22.2: icmp_seq=75 ttl=52 time=155 ms
64 bytes from 216.66.22.2: icmp_seq=77 ttl=52 time=191 ms
64 bytes from 216.66.22.2: icmp_seq=78 ttl=52 time=163 ms
64 bytes from 216.66.22.2: icmp_seq=79 ttl=52 time=160 ms
64 bytes from 216.66.22.2: icmp_seq=83 ttl=52 time=194 ms
64 bytes from 216.66.22.2: icmp_seq=88 ttl=52 time=174 ms
64 bytes from 216.66.22.2: icmp_seq=89 ttl=52 time=151 ms
64 bytes from 216.66.22.2: icmp_seq=93 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=96 ttl=52 time=156 ms
64 bytes from 216.66.22.2: icmp_seq=97 ttl=52 time=169 ms
64 bytes from 216.66.22.2: icmp_seq=98 ttl=52 time=157 ms
64 bytes from 216.66.22.2: icmp_seq=102 ttl=52 time=152 ms
64 bytes from 216.66.22.2: icmp_seq=103 ttl=52 time=166 ms
64 bytes from 216.66.22.2: icmp_seq=104 ttl=52 time=190 ms
64 bytes from 216.66.22.2: icmp_seq=121 ttl=52 time=149 ms
64 bytes from 216.66.22.2: icmp_seq=122 ttl=52 time=156 ms
64 bytes from 216.66.22.2: icmp_seq=123 ttl=52 time=189 ms
64 bytes from 216.66.22.2: icmp_seq=126 ttl=52 time=158 ms
64 bytes from 216.66.22.2: icmp_seq=129 ttl=52 time=154 ms
64 bytes from 216.66.22.2: icmp_seq=130 ttl=52 time=156 ms
64 bytes from 216.66.22.2: icmp_seq=131 ttl=52 time=155 ms
64 bytes from 216.66.22.2: icmp_seq=134 ttl=52 time=161 ms
64 bytes from 216.66.22.2: icmp_seq=139 ttl=52 time=155 ms
64 bytes from 216.66.22.2: icmp_seq=141 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=146 ttl=52 time=202 ms
64 bytes from 216.66.22.2: icmp_seq=147 ttl=52 time=168 ms
64 bytes from 216.66.22.2: icmp_seq=149 ttl=52 time=179 ms
64 bytes from 216.66.22.2: icmp_seq=150 ttl=52 time=158 ms
64 bytes from 216.66.22.2: icmp_seq=151 ttl=52 time=153 ms
64 bytes from 216.66.22.2: icmp_seq=160 ttl=52 time=154 ms
64 bytes from 216.66.22.2: icmp_seq=161 ttl=52 time=150 ms
64 bytes from 216.66.22.2: icmp_seq=162 ttl=52 time=160 ms
64 bytes from 216.66.22.2: icmp_seq=166 ttl=52 time=156 ms
64 bytes from 216.66.22.2: icmp_seq=170 ttl=52 time=170 ms
64 bytes from 216.66.22.2: icmp_seq=172 ttl=52 time=165 ms
64 bytes from 216.66.22.2: icmp_seq=176 ttl=52 time=161 ms
64 bytes from 216.66.22.2: icmp_seq=178 ttl=52 time=208 ms
64 bytes from 216.66.22.2: icmp_seq=183 ttl=52 time=163 ms
--- 216.66.22.2 ping statistics ---
186 packets transmitted, 70 received, 62% packet loss, time 185764ms
rtt min/avg/max/mdev = 145.050/161.883/208.227/13.178 ms
2 12:39:52 root@rootin:~ 0#
3 12:44:58 rchandra@rootin:~ 0> traceroute -n 216.66.22.2
traceroute to 216.66.22.2 (216.66.22.2), 30 hops max, 38 byte packets
1 67.246.160.1 94.489 ms 89.101 ms 111.141 ms
2 98.0.2.97 15.305 ms 11.857 ms 10.861 ms
3 98.0.3.14 61.348 ms 9.715 ms 9.462 ms
4 98.0.3.3 46.964 ms 10.388 ms 19.738 ms
5 107.14.19.28 45.777 ms 66.109.6.72 57.691 ms 42.615 ms
6 107.14.19.35 44.976 ms 41.779 ms 66.109.6.24 46.660 ms
7 107.14.17.169 74.804 ms 66.109.6.159 42.650 ms 107.14.17.169 42.173 ms
8 216.55.0.117 56.098 ms 216.55.0.61 44.905 ms 40.516 ms
9 216.156.1.9 43.318 ms 42.409 ms 57.868 ms
10 216.156.0.17 49.682 ms 45.061 ms 62.770 ms
11 * * *
12 206.111.13.94 52.393 ms 48.864 ms 50.136 ms
13 72.52.92.86 60.227 ms 73.158 ms 84.053 ms
14 216.66.22.2 61.569 ms 60.244 ms 61.870 ms
3 12:45:25 rchandra@rootin:~ 0>
As we can see, it looks like hop 11 from me was having some troubles. It has however "cleared itself up."
Actually, I may have spoken too soon. tserv2.ash1.he.net is having IPv4 connectivity issues again. It's been off again, on again.
(root@BGHost)(~)>ping -n 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_req=1 ttl=54 time=131 ms
64 bytes from 216.66.22.2: icmp_req=2 ttl=54 time=131 ms
64 bytes from 216.66.22.2: icmp_req=3 ttl=54 time=131 ms
64 bytes from 216.66.22.2: icmp_req=4 ttl=54 time=130 ms
64 bytes from 216.66.22.2: icmp_req=5 ttl=54 time=130 ms
^C
--- 216.66.22.2 ping statistics ---
6 packets transmitted, 5 received, 16% packet loss, time 5003ms
rtt min/avg/max/mdev = 130.475/130.911/131.264/0.271 ms
(root@BGHost)(~)>traceroute -n 216.66.22.2
traceroute to 216.66.22.2 (216.66.22.2), 30 hops max, 60 byte packets
1 77.71.10.1 0.295 ms 0.258 ms 0.239 ms
2 77.71.0.145 0.375 ms 0.374 ms 0.366 ms
3 77.71.1.169 0.487 ms 0.484 ms 0.455 ms
4 95.158.130.117 0.787 ms 0.776 ms 0.759 ms
5 145.236.236.110 8.923 ms 8.945 ms 8.908 ms
6 95.158.128.254 8.664 ms 8.734 ms 8.764 ms
7 95.158.128.253 8.746 ms 8.842 ms 8.810 ms
8 80.81.192.172 43.758 ms 50.276 ms 43.693 ms
9 72.52.92.89 52.510 ms 53.127 ms 53.097 ms
10 184.105.213.93 134.209 ms 128.547 ms 129.103 ms
11 184.105.213.93 129.521 ms 216.66.22.2 131.064 ms 131.019 ms
Quote from: rchandra on June 05, 2012, 10:21:00 AMAs we can see, it looks like hop 11 from me was having some troubles. It has however "cleared itself up."
Having some individual hops in the traceroute output not show any replies doesn't necessarily mean there is a problem. It its not unusual to see a hop that forwards packets without drops, but only sends TTL expired replies for 1% of packets and drop the other 99% for which a TTL expired reply would have been sent. Part of the reason for this is that some routers can do the packet forwarding in hardware, but can only send the TTL expired reply in software. The CPU just cannot handle the same rate of packets as the hardware forwarding engine.
Quote from: rchandra on June 05, 2012, 11:25:17 AMActually, I may have spoken too soon. tserv2.ash1.he.net is having IPv4 connectivity issues again. It's been off again, on again.
What does ash1 have to do with it? The addresses I saw previously resolve to lax1.
As far as the traces dropping off at that one point...good point. It's sometimes a weak diagnostic in that respect. Subsequent to that though, I was doing traces with 10 queries per hop, and then 10 ICMP queries (the -I option), and the tests were stopping at that hop and the 12th as well. It just seemed to be the bottleneck point. And it has been happening inconsistently today; sometimes just fine, sometimes lots of packet loss.
ash1 is the tunnel endpoint I use. If the OP was using something else, well...perhaps it was something more widespread than just that one PoP. I see now the one line that the endpoint IP address is not the same as the one I use. I hope I was not a hindrance providing more data points.
Try to disable "ipv6 inspect V6-INSPECT out" from the tunnel interface and see if it's better.