Slow speeds through HE IPv6 tunnel

[mightymouse2045]

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:




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

[kasperd]

The first thing I noticed was a high latency to your tunnel.

Code Select Expand

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 msThe 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?

[rchandra]

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).

Code Select Expand

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#

Code Select Expand

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."

[rchandra]

Actually, I may have spoken too soon.  tserv2.ash1.he.net is having IPv4 connectivity issues again.  It's been off again, on again.

[campari]

(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

[kasperd]

As 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.

Actually, 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.

[rchandra]

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.

[bjoxaa]

Try to disable "ipv6 inspect V6-INSPECT out" from the tunnel interface and see if it's better.