|
Slow tunnel (Fritzbox, Heartbeat, Austria via Slovenia)
![[at]](/s/countries/at.gif) Shadow Hawkins on Sunday, 04 October 2015 19:56:17
Hello everyone,
I set up a heartbeat tunnel a few weeks ago using the built-in function of my Fritz!Box 7360SL provided by my ISP (UPC.at).
Most of the times it works fine (works pretty well although it has a prety high packet loss. according to tunnel statistics over 50% almost all the time...) but since two days the tunnel is extremely slow (~100-200Kbit per second according to the speedtest and a download from my VPS hosted by EDIS in Austria) but the ipv4 connection still works perfectly fine.
I don't really know how to further debug this problem so I would be thankful for any help.
I have good knowledge about networks/routing, Linux and other things but I currently have no clue why the speed is so bad...
My PoP is simbx0 and my tunnel-ID is T170517.
The live tunnel status doesn't show anything bad (no errors, only 130 total packets too big since tunnel creation)
If I can provide you with any additional details that I forgot please don't hesitate to ask.
Thanks
Jakob Riepler
Slow tunnel (Fritzbox, Heartbeat, Austria via Slovenia)
Did you read FAQ : Connectivity (Tunnels and Subnets) : The tunnel is slow? There are lots of factors involved in "slow".
ISP (UPC.at).
UPC.at does DS-Lite if you want it. (likely answer is: no).
They also have some ratelimiting in their network when their bandwidth load gets high.
(works pretty well although it has a prety high packet loss. according to tunnel statistics over 50% almost all the time...)
Packet loss in the graphs means that your endpoint did not respond to the ICMPv6 echo request packets from the PoP. Can be caused by a lot of factors, see above.
(~100-200Kbit per second according to the speedtest
"the Speedtest", which "speedtest" is that? Noting that you are very likely testing bandwidth over a very weird route totally outside the path between you, the PoP and whatever resources you are normally accessing.
and a download from my VPS hosted by EDIS in Austria)
You are aware that EDIS is a cheap and oversubscribed network right? :)
I don't really know how to further debug this problem so I would be thankful for any help.
See the FAQ item mentioned above.
I have good knowledge about networks/routing
If you do, why did you not include for instance a traceroute?
but I currently have no clue why the speed is so bad...
Nor did you check the FAQ which has a list of things to look at.
The live tunnel status doesn't show anything bad (no errors, only 130 total packets too big since tunnel creation)
Packets Too Big are actually good. Those counters are not 'since tunnel creation'.
If I can provide you with any additional details that I forgot please don't hesitate to ask.
As mentioned by the big orange/yellow boxes when posting, see the "Reporting Problems section" for those details... oh and also check the FAQ.
Slow tunnel (Fritzbox, Heartbeat, Austria via Slovenia)
Shadow Hawkins on Sunday, 04 October 2015 21:34:44
Thank you for answering so quickly.
I don't think UPC does rate limiting as the ipv4 speed is the normal 13MBit/s I get via ADSL2+ (they could use QoS to slow down 6in4 though...).
The speedtest I was talking about is this one.
Also I tested the speed using a server hosted by OVH in Frankfurt now to make sure it wasn't my server which limits the bandwidth.
Sorry that I forgot the traceroute... I forgot to add it (I did one and planed on adding it to my report but forgot...)
Here is a traceroute from my PC to the PoP (IPv4):
traceroute to 212.18.63.73 (212.18.63.73), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 0.374 ms 0.423 ms 0.495 ms
2 217.25.112.3 (217.25.112.3) 33.105 ms 34.189 ms 35.790 ms
3 84.116.229.173 (84.116.229.173) 38.553 ms 40.562 ms 41.906 ms
4 at-vie-sk11-pe05-vl-2013.upc.at (84.116.228.5) 57.821 ms 58.895 ms 60.232 ms
5 at-vie01a-rd1-vl-2047.aorta.net (84.116.228.145) 61.173 ms 63.004 ms 64.963 ms
6 de-fra03a-rd1-xe-1-2-0.aorta.net (213.46.160.102) 66.169 ms 47.769 ms 54.915 ms
7 de-fra03b-ri1-ge-4-1-0.aorta.net (84.116.130.206) 48.611 ms de-fra01a-ri2-xe-4-1-1.aorta.net (84.116.133.118) 49.488 ms 84.116.133.97 (84.116.133.97) 52.695 ms
8 ae-10.r03.frnkge03.de.bb.gin.ntt.net (80.81.192.46) 82.532 ms 83.600 ms 84.061 ms
9 ae-21.r02.frnkge03.de.bb.gin.ntt.net (129.250.6.84) 97.213 ms 86.375 ms 89.246 ms
10 ae-1.r00.vienat01.at.bb.gin.ntt.net (129.250.2.161) 88.476 ms 91.624 ms 92.482 ms
11 83.231.187.10 (83.231.187.10) 95.457 ms 95.308 ms 97.019 ms
12 mx-mb-te-1-2-1.amis.net (212.18.44.149) 90.243 ms 91.543 ms 96.289 ms
13 maribor3-te-7-4.amis.net (212.18.44.134) 203.594 ms 204.444 ms 204.446 ms
14 simbx01.sixxs.net (212.18.63.73) 100.101 ms 104.153 ms 92.801 ms
And one to my server via IPv6 (using the tunnel):
traceroute to chaosfield.at (2a03:f80:ed15:151:236:12:222:1) from 2001:15c0:65ff:8846:cdc5:8e04:973f:6df5, 30 hops max, 24 byte packets
1 2001:15c0:65ff:8846:a96:d7ff:fe91:ea4e (2001:15c0:65ff:8846:a96:d7ff:fe91:ea4e) 0.594 ms 0.409 ms 0.35 ms
2 gw-2119.mbx-01.si.sixxs.net (2001:15c0:65ff:846::1) 91.019 ms 91.108 ms 88.266 ms
3 simbx01.sixxs.net (2001:15c0:ffff:7::2) 86.922 ms 94.063 ms 89.914 ms
4 * mx-mb1-te-1-2-0-v4.amis.net (2001:15c0:ffff:7::1) 90.607 ms 90.259 ms
5 mx-mb1-te-1-3-1.amis.net (2001:15c0:ffff:d::c) 89.379 ms * 91.455 ms
6 mx-vi1-te-0-0-1.amis.net (2001:15c0:ffff:d::3) 92.421 ms 91.358 ms 91.485 ms
7 2001:7f8:30:0:2:1:0:9002 (2001:7f8:30:0:2:1:0:9002) 92.36 ms 94.52 ms 124.933 ms
8 GW-EDIS.retn.net (2a02:2d8:0:a001:232a::1) 98.045 ms 94.547 ms 138.795 ms
9 2a03:f80:ed15:151:236:12:222:1 (2a03:f80:ed15:151:236:12:222:1) 99.051 ms 97.5 ms 98.785 ms
Also a packet dump on the Fritz!Box's internet interface did not reveal anything (no abnormalities or things that could be a problem with the tunnel)
I did read the FAQ page and I'm sorry that I forgot to include the traceroutes...
I hope I now listed all the infos I can provide.
Slow tunnel (Fritzbox, Heartbeat, Austria via Slovenia)
I don't think UPC does rate limiting as the ipv4 speed is the normal 13MBit/s I get via ADSL2+ (they could use QoS to slow down 6in4 though...).
Other users have done testing and proven that non-port-80/443 are prioritised over other traffic, and 6in4/AYIYA etc are "other traffic".
The speedtest I was talking about is this one.
Their servers are in bad locations with low speed, thus that test is totally useless.
Also I tested the speed using a server hosted by OVH in Frankfurt now to make sure it wasn't my server which limits the bandwidth.
OVH has a rather bad IPv6 network. Check their forums or google(OVH IPv6), you'll find lots of complaints.
1 192.168.1.254 (192.168.1.254) 0.374 ms 0.423 ms 0.495 ms
You are behind a NAT. How does that NAT handle your tunneled packets?
13 maribor3-te-7-4.amis.net (212.18.44.134) 203.594 ms 204.444 ms 204.446 ms
AORTA (UPC backbone) still is a lousy peerer. See the latency variations, they are insane.
14 simbx01.sixxs.net (212.18.63.73) 100.101 ms 104.153 ms 92.801 ms
[..]
9 2a03:f80:ed15:151:236:12:222:1 (2a03:f80:ed15:151:236:12:222:1) 99.051 ms 97.5 ms 98.785 ms
All of that latency is IPv4 overhead.
Also a packet dump on the Fritz!Box's internet interface did not reveal anything (no abnormalities or things that could be a problem with the tunnel)
If you are terminating the tunnel on a Fritz!Box do realize that a Fritz!Box has a tiny CPU that has to process the tunneled packets as it does not process them in hardware.
I did read the FAQ page and I'm sorry that I forgot to include the traceroutes... I hope I now listed all the infos I can provide.
As the FAQ page states, there are lots of variables which can lead to "slow".
Your problem most likely is simply UPC though. Unfortunately as they are the monopoly in Europe little that can be done about that.
Slow tunnel (Fritzbox, Heartbeat, Austria via Slovenia)
Shadow Hawkins on Sunday, 04 October 2015 22:19:05
The Fritz!Box handles the tunnel but the CPU is nowhere near full load (and like I wrote in the first post, the tunnel worked fine a few days ago with only minor problems).
I know that UPC is lousy and I really hate them (bad customer support, regular problems with their routing, ...) but they are currently my only usable option :/
The latency isn't really a problem. the problem is that I'm only getting about 100KBit/s through the tunnel since ~2days (and you can't tell me that EDIS, OVH and the speedtest servers are a bottleneck here as it worked fine before...)
I just downloaded a 100MB test file from my server using scp and I could use my full bandwidth of ~1,2MByte/s using IPv4 but only ~20-30KByte/s using IPv6 so they either specifically limit 6in4/heartbeat or whitelisted scp if they apply QoS :/
Also I could get a cable connection with DSLite but the problem is that my dad needs a public IPv4 for his work (the company's VPN requires a public IP and doesn't have IPv6) so it's not really an option...
So I guess I can't really do anything against the slow tunnel speeds except for waiting and/or annoying UPC to get real IPv6?
The next thing I want to try is to start the tunnel on my phone via 3G (I have a public IPv4 there) and see if it works better there. if so the problem most likely is UPC...
Again, thank you very much for your help!
Slow tunnel (Fritzbox, Heartbeat, Austria via Slovenia)
but they are currently my only usable option :/
As I noted, that is the pure definition of a monopoly.
All of Europe has the UPC (Liberty Global) problem, the US has their Comcast for that.
the problem is that I'm only getting about 100KBit/s through the tunnel since ~2days
Which can be caused due to a lot of factors. See the FAQ.
The PoP itself fetches data perfectly fine from eg mirror.switch.ch (which takes a path over cogent) at 100mbit.
(and you can't tell me that EDIS, OVH and the speedtest servers are a bottleneck here as it worked fine before...
The path towards them can be. The Internet is a big and dynamic place.
Note also, as per the FAQ, that your path involves both IPv4 and IPv6 layers.
specifically limit 6in4/heartbeat
Or just bucket it as "other". As I noted UPC is know to do that.
Note that "heartbeat" is a signaling protocol, the single packet it sends once in a while only indicates your tunnel endpoint location. It has no effect on throughput or latency. (unless your path is so overloaded that those packets make it even more overloaded, but then you have a really bad connection).
Also I could get a cable connection with DSLite but the problem is that my dad needs a public IPv4 for his work (the company's VPN requires a public IP and doesn't have IPv6) so it's not really an option...
DS-Lite is not a good option either way, they only have it so that the IPv4 addresses can go to the more-paying customers, noting that UPC has more than enough space for all their customers and also that cable modem, that horizon box etc all get public IPv4 addresses at the moment, they have the space, they just want people to cough up extra money for it. IPv6 is the right goal though, DS-LIte completely destroys usability for IPv4 for many situations, eg try playing a game with a Playstation or on PC where the games are not IPv6 enabled yet.
The next thing I want to try is to start the tunnel on my phone via 3G (I have a public IPv4 there)
Even if you are lucky to have a public IPv4, it might not mean they allow proto-41 though...
|
![[ch]](/s/countries/ch.gif)
on Sunday, 04 October 2015 20:22:28
Posting is only allowed when you are