|
Ticket ID: SIXXS #9173114 Ticket Status: Remote Problem PoP: simbx01 - Amis (Maribor)
Packet loss (IPv4 & IPv6)
![[at]](/s/countries/at.gif) Shadow Hawkins on Thursday, 11 April 2013 08:44:17
There seems to be a packet loss on simbx01. My IPv4 connection works without problems but if I ping the remote tunnel endpoint (both IPv4 and IPv6), some packets are lost. Also the latency is quite high.
I don't believe it's a problem with my setup because pinging the remote tunnel endpoint from another location (native IPv6; AS24940) also results in packet loss:
IPv6 ping from remote location (AS24940):
# ping6 -c 20 2001:xx::1
PING 2001:xx::1(2001:xx::1) 56 data bytes
64 bytes from 2001:xx::1: icmp_seq=1 ttl=55 time=83.9 ms
64 bytes from 2001:xx::1: icmp_seq=2 ttl=55 time=51.5 ms
64 bytes from 2001:xx::1: icmp_seq=5 ttl=55 time=424 ms
64 bytes from 2001:xx::1: icmp_seq=6 ttl=55 time=21.4 ms
64 bytes from 2001:xx::1: icmp_seq=7 ttl=55 time=19.7 ms
64 bytes from 2001:xx::1: icmp_seq=8 ttl=55 time=89.3 ms
64 bytes from 2001:xx::1: icmp_seq=9 ttl=55 time=587 ms
64 bytes from 2001:xx::1: icmp_seq=10 ttl=55 time=52.9 ms
64 bytes from 2001:xx::1: icmp_seq=11 ttl=55 time=216 ms
64 bytes from 2001:xx::1: icmp_seq=12 ttl=55 time=417 ms
64 bytes from 2001:xx::1: icmp_seq=15 ttl=55 time=204 ms
64 bytes from 2001:xx::1: icmp_seq=16 ttl=55 time=19.6 ms
64 bytes from 2001:xx::1: icmp_seq=17 ttl=55 time=57.3 ms
64 bytes from 2001:xx::1: icmp_seq=18 ttl=55 time=26.0 ms
64 bytes from 2001:xx::1: icmp_seq=19 ttl=55 time=485 ms
64 bytes from 2001:xx::1: icmp_seq=20 ttl=55 time=122 ms
--- 2001:xx::1 ping statistics ---
20 packets transmitted, 16 received, 20% packet loss, time 19049ms
rtt min/avg/max/mdev = 19.698/180.042/587.915/184.811 ms
IPv4 ping from remote location (AS24940):
# ping -c 20 212.18.63.73
PING 212.18.63.73 (212.18.63.73) 56(84) bytes of data.
64 bytes from 212.18.63.73: icmp_req=2 ttl=56 time=81.1 ms
64 bytes from 212.18.63.73: icmp_req=3 ttl=56 time=19.8 ms
64 bytes from 212.18.63.73: icmp_req=4 ttl=56 time=30.4 ms
64 bytes from 212.18.63.73: icmp_req=5 ttl=56 time=19.3 ms
64 bytes from 212.18.63.73: icmp_req=6 ttl=56 time=148 ms
64 bytes from 212.18.63.73: icmp_req=7 ttl=56 time=20.1 ms
64 bytes from 212.18.63.73: icmp_req=8 ttl=56 time=142 ms
64 bytes from 212.18.63.73: icmp_req=9 ttl=56 time=79.8 ms
64 bytes from 212.18.63.73: icmp_req=10 ttl=56 time=77.4 ms
64 bytes from 212.18.63.73: icmp_req=11 ttl=56 time=157 ms
64 bytes from 212.18.63.73: icmp_req=13 ttl=56 time=179 ms
64 bytes from 212.18.63.73: icmp_req=14 ttl=56 time=160 ms
64 bytes from 212.18.63.73: icmp_req=15 ttl=56 time=128 ms
64 bytes from 212.18.63.73: icmp_req=17 ttl=56 time=182 ms
64 bytes from 212.18.63.73: icmp_req=18 ttl=56 time=19.5 ms
64 bytes from 212.18.63.73: icmp_req=19 ttl=56 time=87.6 ms
64 bytes from 212.18.63.73: icmp_req=20 ttl=56 time=107 ms
--- 212.18.63.73 ping statistics ---
20 packets transmitted, 17 received, 15% packet loss, time 19009ms
rtt min/avg/max/mdev = 19.334/96.629/182.722/57.894 ms
I use pfSense 2.1 Beta (4G VGA amd64, snapshot from April 10 2013) to setup the tunnel and propagate the subnet in my LAN. It's also the border router of my LAN, so no NAT is involved. It worked flawlessly until about two days ago. The IPv4 connection is stable.
IPv6 ping from my pfSense box to the remote tunnel endpoint:
PING6(56=40+8+8 bytes) 2001:1xx::2 --> 2001:xx::1
16 bytes from 2001:xx::1, icmp_seq=0 hlim=64 time=419.660 ms
16 bytes from 2001:xx::1, icmp_seq=1 hlim=64 time=207.605 ms
16 bytes from 2001:xx::1, icmp_seq=2 hlim=64 time=246.117 ms
16 bytes from 2001:xx::1, icmp_seq=3 hlim=64 time=537.640 ms
16 bytes from 2001:xx::1, icmp_seq=4 hlim=64 time=507.778 ms
16 bytes from 2001:xx::1, icmp_seq=6 hlim=64 time=476.816 ms
16 bytes from 2001:xx::1, icmp_seq=7 hlim=64 time=419.501 ms
16 bytes from 2001:xx::1, icmp_seq=9 hlim=64 time=637.826 ms
--- 2001:xx::1 ping6 statistics ---
10 packets transmitted, 8 packets received, 20.0% packet loss
round-trip min/avg/max/std-dev = 207.605/431.618/637.826/135.318 ms
IPv4 ping from my pfSense box to the IPv4 tunnel endpoint:
PING 212.18.63.73 (212.18.63.73): 56 data bytes
64 bytes from 212.18.63.73: icmp_seq=2 ttl=57 time=66.112 ms
64 bytes from 212.18.63.73: icmp_seq=3 ttl=57 time=14.228 ms
64 bytes from 212.18.63.73: icmp_seq=4 ttl=57 time=53.321 ms
64 bytes from 212.18.63.73: icmp_seq=5 ttl=57 time=93.227 ms
64 bytes from 212.18.63.73: icmp_seq=6 ttl=57 time=133.183 ms
64 bytes from 212.18.63.73: icmp_seq=7 ttl=57 time=73.591 ms
64 bytes from 212.18.63.73: icmp_seq=8 ttl=57 time=37.173 ms
64 bytes from 212.18.63.73: icmp_seq=9 ttl=57 time=14.904 ms
--- 212.18.63.73 ping statistics ---
10 packets transmitted, 8 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 14.228/60.717/133.183/37.703 ms
traceroute (IPv4) from my pfSense box:
1 * * *
2 84.116.4.145 (84.116.4.145) 10.887 ms 12.206 ms 24.859 ms
3 at-vie01a-rd1-vl-2020.aorta.net (84.116.228.37) 11.545 ms 8.389 ms 9.412 ms
4 at-vie05b-ri2-xe-3-2-0.aorta.net (213.46.173.117) 9.820 ms 12.673 ms 9.400 ms
5 at-inn01a-ra1-so-1-0-0-0.aorta.net (213.46.173.226) 9.390 ms 12.684 ms 9.526 ms
6 amis-gw.ip4.tinet.net (77.67.75.94) 25.588 ms 7.247 ms 9.846 ms
7 mx-mb-te-1-2-1.amis.net (212.18.44.149) 35.575 ms 12.690 ms 13.695 ms
8 simbx01.sixxs.net (212.18.63.73) 47.585 ms * 167.358 ms
IPv6 traceroute is useless because the remote tunnel endpoint is the nexhop.
Thanks!
Regards,
Thomas
Packet loss (IPv4 & IPv6)
My IPv4 connection works without problems
Towards which destination and over which paths?
but if I ping the remote tunnel endpoint (both IPv4 and IPv6), some packets are lost.
What is the path?
I don't believe it's a problem with my setup because pinging the remote tunnel endpoint from another location (native IPv6; AS24940) also results in packet loss:
What are the exact source and destination addresses, and what is the path that these packets flow over?
I use pfSense 2.1 Beta (4G VGA amd64, snapshot from April 10 2013) to setup the tunnel and propagate the subnet in my LAN.
As we do not have access to that (and quite about every other) environment, what exactly does that entail?
The IPv4 connection is stable.
What part of that connection?
IPv6 ping from my pfSense box to the remote tunnel endpoint:
Without exact source and destination addresses and a path quite useless.
Also note that QoS and other such features can cause the issues that you describe. But without more details, hard to tell.
Packet loss (IPv4 & IPv6)
Shadow Hawkins on Thursday, 11 April 2013 10:01:06
Thanks for the quick reply!
Could you please try to ping the remote endpoints of the simbx01 PoP.
My endpoints are:
IPv4: 212.18.63.73
IPv6: 2001:15c0:65ff:62c::1
I tried to ping that IP addresses from other locations than my home internet as well.
I used http://www.berkom.blazing.de/tools/ping.cgi for IPv6 and http://ping.eu/ping/ for IPv4 and there is also a packet loss.
When using my root server at Hetzner to ping the endpoints I also get packet loss (with both IPv4 and IPv6).
Because the loss is about 10-30% I pinged the endpoints more than just 4 times.
That's why I thinks there's not a problem with my home network. Besides, everything worked just fine until two days ago and I didn't change anything.
At first I thought that there's a problem with my internet connection but I've no problems when surfing with IPv4.
Then I tried to ping the PoP endpoints from other locations and there's also a packet loss.
Some tests from my root server (IPv4: 46.4.28.250, IPv6: 2a01:4f8:131:4ffd:1::2):
# ping -c 20 212.18.63.73
PING 212.18.63.73 (212.18.63.73) 56(84) bytes of data.
64 bytes from 212.18.63.73: icmp_req=1 ttl=56 time=19.6 ms
64 bytes from 212.18.63.73: icmp_req=3 ttl=56 time=19.7 ms
64 bytes from 212.18.63.73: icmp_req=4 ttl=56 time=19.5 ms
64 bytes from 212.18.63.73: icmp_req=5 ttl=56 time=197 ms
64 bytes from 212.18.63.73: icmp_req=6 ttl=56 time=167 ms
64 bytes from 212.18.63.73: icmp_req=7 ttl=56 time=21.0 ms
64 bytes from 212.18.63.73: icmp_req=8 ttl=56 time=19.5 ms
64 bytes from 212.18.63.73: icmp_req=9 ttl=56 time=19.5 ms
64 bytes from 212.18.63.73: icmp_req=10 ttl=56 time=19.7 ms
64 bytes from 212.18.63.73: icmp_req=11 ttl=56 time=53.6 ms
64 bytes from 212.18.63.73: icmp_req=12 ttl=56 time=62.7 ms
64 bytes from 212.18.63.73: icmp_req=13 ttl=56 time=19.5 ms
64 bytes from 212.18.63.73: icmp_req=17 ttl=56 time=53.2 ms
64 bytes from 212.18.63.73: icmp_req=18 ttl=56 time=20.8 ms
64 bytes from 212.18.63.73: icmp_req=19 ttl=56 time=225 ms
64 bytes from 212.18.63.73: icmp_req=20 ttl=56 time=163 ms
--- 212.18.63.73 ping statistics ---
20 packets transmitted, 16 received, 20% packet loss, time 19009ms
rtt min/avg/max/mdev = 19.507/68.828/225.118/71.377 ms
# ping6 -c 20 2001:15c0:65ff:62c::1
PING 2001:15c0:65ff:62c::1(2001:15c0:65ff:62c::1) 56 data bytes
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=4 ttl=55 time=340 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=5 ttl=55 time=94.5 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=6 ttl=55 time=19.7 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=7 ttl=55 time=161 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=8 ttl=55 time=77.6 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=9 ttl=55 time=51.7 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=10 ttl=55 time=38.9 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=11 ttl=55 time=39.1 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=15 ttl=55 time=156 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=16 ttl=55 time=154 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=17 ttl=55 time=134 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=18 ttl=55 time=19.5 ms
64 bytes from 2001:15c0:65ff:62c::1: icmp_seq=19 ttl=55 time=138 ms
--- 2001:15c0:65ff:62c::1 ping statistics ---
20 packets transmitted, 13 received, 35% packet loss, time 19061ms
rtt min/avg/max/mdev = 19.573/109.880/340.988/84.434 ms
# traceroute 212.18.63.73
traceroute to 212.18.63.73 (212.18.63.73), 30 hops max, 60 byte packets
1 lilly.trinet.at (46.4.28.205) 0.836 ms 0.779 ms 0.766 ms
2 static.193.28.4.46.clients.your-server.de (46.4.28.193) 1.212 ms 1.291 ms 1.284 ms
3 hos-tr1.juniper1.rz13.hetzner.de (213.239.224.1) 0.698 ms 0.682 ms hos-tr4.juniper2.rz13.hetzner.de (213.239.224.97) 0.670 ms
4 hos-bb2.juniper4.ffm.hetzner.de (213.239.240.150) 6.665 ms 6.665 ms 6.379 ms
5 frankfurt1-ge-1-13-2004.amis.net (80.81.194.77) 16.163 ms 16.019 ms 16.237 ms
6 mx-mb-te-1-2-1.amis.net (212.18.44.149) 19.905 ms 19.598 ms 19.566 ms
7 simbx01.sixxs.net (212.18.63.73) 206.558 ms 206.524 ms 206.540 ms
# traceroute6 2001:15c0:65ff:62c::1
traceroute to 2001:15c0:65ff:62c::1 (2001:15c0:65ff:62c::1), 30 hops max, 80 byte packets
1 lilly.trinet.at (2a01:4f8:131:4ffd:1::1) 0.607 ms 0.561 ms 0.545 ms
2 2a01:4f8:131:44c0::1 (2a01:4f8:131:44c0::1) 1.715 ms 1.703 ms 15.818 ms
3 hos-tr4.juniper2.rz13.hetzner.de (2a01:4f8:0:13:4:0:13:2) 0.746 ms hos-tr3.juniper2.rz13.hetzner.de (2a01:4f8:0:13:3:0:13:2) 0.746 ms hos-tr1.juniper1.rz13.hetzner.de (2a01:4f8:0:13:1:0:13:1) 0.688 ms
4 hos-bb2.juniper4.ffm.hetzner.de (2a01:4f8:0:2::1:4) 6.626 ms 6.579 ms 6.570 ms
5 frankfurt1-ge-1-13-2004.amis.net (2001:7f8::218f:0:1) 16.140 ms 16.159 ms 16.083 ms
6 maribor3-te-1-3.amis.net (2001:15c0:ffff:d::2) 34.240 ms 19.486 ms 19.778 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * gw-1581.mbx-01.si.sixxs.net (2001:15c0:65ff:62c::1) 96.358 ms 96.268 ms
Thanks for your help!
Packet loss (IPv4 & IPv6)
Could you please try to ping the remote endpoints of the simbx01 PoP.
Please note that the PoP pings these regularly. See your tunnel details page for the statistics.
That's why I thinks there's not a problem with my home network.
Likely there is not, but there might be issues on this rather big changing thing called the Internet.
I didn't change anything.
In your part of the setup, but the rest of the Internet might have changes in usage and configuration that might affect this path. Hence the question about traceroutes to see the actual path.
Though a traceroute only shows one way of the path (the return path), and not the forward and problems might occur on either of them.
Packet loss (IPv4 & IPv6)
Shadow Hawkins on Thursday, 11 April 2013 10:25:05Please note that the PoP pings these regularly. See your tunnel details page for the statistics.
The PoP pings my endpoints, right? My IPv6 tunnel endpoint (2001:15c0:65ff:62c::2) and my IPv4 address, but not itself (i.e. 212.18.63.73, 2001:15c0:65ff:62c::1).
Or does it ping itself, too? On the RRD graphs in on my tunnel details page there are also these packet losses.
Likely there is not, but there might be issues on this rather big changing thing called the Internet. In your part of the setup, but the rest of the Internet might have changes in usage and configuration that might affect this path. Hence the question about traceroutes to see the actual path. Though a traceroute only shows one way of the path (the return path), and not the forward and problems might occur on either of them.
Okay, so I'll just wait for BGP to solve the problem ;)
Thanks,
Regards, Thomas
Packet loss (IPv4 & IPv6)
The PoP pings my endpoints, right? My IPv6 tunnel endpoint (2001:15c0:65ff:62c::2) and my IPv4 address, but not itself (i.e. 212.18.63.73, 2001:15c0:65ff:62c::1). Or does it ping itself, too? On the RRD graphs in on my tunnel details page there are also these packet losses.
As described in the FAQ, the PoP pings in IPv6 from the PoP side of the tunnel to the user's side of the tunnel.
Packet loss (IPv4 & IPv6)
Shadow Hawkins on Monday, 24 June 2013 12:30:57
I have the same problem!
I ping (IPv4) simbx01.sixxs.net from my home network and from the Vienna University of Technology.
Packet loss (IPv4 & IPv6)
And with more and more people doing pings the chance that it is an ICMP rate limiter somewhere increases.
Without exact details there is little more we can say about your statement though.
Packet loss (IPv4 & IPv6)
Shadow Hawkins on Thursday, 04 July 2013 07:44:15And with more and more people doing pings the chance that it is an ICMP rate limiter somewhere increases.
Well, I've got the same problem again. It's been a few weeks now, that I have packet loss on my tunnel.
I had to disable the router advertisments on my LAN subnet, because IPv6 connections constantly hang and/or are slow (Facebook, SSH connections,...)
So it doesn't seem like a ICMP rate limiter, because the connection really breaks (i.e. ssh connection hangs or disconnects).
I tried to ping the IPv4 endpoint of simbx01 (212.18.63.73) from 4 different AS and I've got packet loss of about 5-7% on every AS.
When I ping maribor3-te-7-4.amis.net (212.18.44.134), the last hop before simbx01 (212.18.63.73) there is no packet loss.
Without exact details there is little more we can say about your statement though.
What exact details do you need?
Traceroute?
from AS6830 (my home net):
~# traceroute 212.18.63.73
traceroute to 212.18.63.73 (212.18.63.73), 30 hops max, 60 byte packets
1 pia.home.rieschl.com (192.168.14.1) 0.144 ms 0.123 ms 0.143 ms
2 * * *
3 84.116.4.145 (84.116.4.145) 12.367 ms 12.390 ms 12.373 ms
4 at-vie01a-rd1-vl-2020.aorta.net (84.116.228.37) 12.356 ms 12.359 ms 12.897 ms
5 at-vie05b-ri2-xe-3-2-0.aorta.net (213.46.173.117) 12.929 ms 12.973 ms 12.858 ms
6 at-inn01a-ra1-so-1-0-0-0.aorta.net (213.46.173.226) 91.144 ms 89.240 ms 89.216 ms
7 amis-gw.ip4.tinet.net (77.67.75.94) 10.943 ms 12.724 ms 12.724 ms
8 mx-mb-te-1-2-1.amis.net (212.18.44.149) 16.274 ms 16.309 ms 16.314 ms
9 maribor3-te-7-4.amis.net (212.18.44.134) 15.649 ms 15.763 ms 15.768 ms
10 simbx01.sixxs.net (212.18.63.73) 35.028 ms 34.960 ms *
from AS20751:
~# traceroute 212.18.63.73
traceroute to 212.18.63.73 (212.18.63.73), 30 hops max, 60 byte packets
1 vl-1878.dc1cs1.vienna.at.cix.at (80.64.132.254) 1.237 ms 1.414 ms 1.693 ms
2 2ge-vl-0990.warp9.dist.azista.net (80.64.128.169) 1.961 ms 2.074 ms 2.188 ms
3 2ge23-0-0992.warp8.azista.net (80.64.128.250) 2.726 ms 2.840 ms 2.932 ms
4 vix.amis.net (193.203.0.117) 2.267 ms 2.394 ms 2.490 ms
5 mx-mb-te-1-2-1.amis.net (212.18.44.149) 4.780 ms 5.024 ms 5.156 ms
6 maribor3-te-7-4.amis.net (212.18.44.134) 4.886 ms 4.331 ms 4.304 ms
7 simbx01.sixxs.net (212.18.63.73) 17.299 ms 17.413 ms 17.516 ms
from AS24940:
~# traceroute 212.18.63.73
traceroute to 212.18.63.73 (212.18.63.73), 30 hops max, 60 byte packets
1 lilly.trinet.at (46.4.28.205) 1.566 ms 1.605 ms 1.592 ms
2 static.193.28.4.46.clients.your-server.de (46.4.28.193) 3.976 ms 4.197 ms 4.195 ms
3 hos-tr4.juniper2.rz13.hetzner.de (213.239.224.97) 1.547 ms hos-tr1.juniper1.rz13.hetzner.de (213.239.224.1) 1.523 ms hos-tr4.juniper2.rz13.hetzner.de (213.239.224.97) 1.525 ms
4 hos-bb2.juniper4.ffm.hetzner.de (213.239.240.150) 6.499 ms hos-bb1.juniper1.ffm.hetzner.de (213.239.240.224) 5.389 ms 5.392 ms
5 frankfurt1-ge-1-13-2004.amis.net (80.81.194.77) 16.145 ms 16.020 ms 15.508 ms
6 mx-mb-te-1-2-1.amis.net (212.18.44.149) 19.729 ms 19.121 ms 19.323 ms
7 maribor3-te-7-4.amis.net (212.18.44.134) 51.196 ms 51.207 ms 51.332 ms
8 simbx01.sixxs.net (212.18.63.73) 18.903 ms 27.561 ms 27.531 ms
from AS1776:
~$ traceroute 212.18.63.73
traceroute to 212.18.63.73 (212.18.63.73), 30 hops max, 60 byte packets
1 gw-sn3.wu-wien.ac.at (137.208.3.1) 0.649 ms 0.716 ms 0.792 ms
2 box-1-19.wu-wien.ac.at (137.208.19.135) 0.507 ms 0.497 ms 0.485 ms
3 ex-1-9.wu-wien.ac.at (137.208.9.21) 0.691 ms 0.659 ms 0.643 ms
4 vlan717.wien1.aco.net (193.171.13.17) 0.824 ms * *
5 vlan71.wien21.aco.net (193.171.23.18) 1.062 ms * *
6 bundle-ether-21-73.core21.aco.net (193.171.23.42) 1.909 ms 1.609 ms 1.614 ms
7 vix.amis.net (193.203.0.117) 1.300 ms 1.313 ms 1.292 ms
8 mx-mb-te-1-2-1.amis.net (212.18.44.149) 4.928 ms 4.936 ms 4.933 ms
9 maribor3-te-7-4.amis.net (212.18.44.134) 4.929 ms 4.970 ms 5.059 ms
10 simbx01.sixxs.net (212.18.63.73) 30.932 ms 30.947 ms 30.943 ms
I really want to use IPv6 again but with those constant packet losses it's just not possible :(
Any help is appreciated!
Packet loss (IPv4 & IPv6)
What exact details do you need?
Many. Figuring out where packet loss is really happening in a layered network (tunneling) is very hard. The packet loss can happen in this case on the IPv4 level, on any of the hops between you and the PoP, and on the IPv6 level, which goes over that path.
See also the FAQ on "my tunnel is slow" for a variety of things that might affect it.
Traceroute?
The traceroutes you show demonstrate that there are packetloss issues on all the paths you provide; traceroutes do not really indicate where that packetloss happens though
Packet loss (IPv4 & IPv6)
Shadow Hawkins on Thursday, 04 July 2013 09:00:53Many. Figuring out where packet loss is really happening in a layered network (tunneling) is very hard. The packet loss can happen in this case on the IPv4 level, on any of the hops between you and the PoP, and on the IPv6 level, which goes over that path.
As there are problems (packet loss) when pinging simbx01.sixxs.net over IPv4 but not when pinging (IPv4) the router before that (maribor3-te-7-4.amis.net) I suspect that the problem lies there.
There's no point pinging something over the IPv6 tunnel because the packet loss happens already on the IPv4 net.
Is it possible that you ask simbx01 to checkt that (and if the apply ICMP rate limits on simbx01.sixxs.net)?
I know, ping is just a very rudimentary tool and not quite able to trace back the real problem, but it's the only thing I can do. Everything outside my network is not under my control, so I can't do anything but point out that there's a problem.
If the problems persist, is it possible to switch to another PoP?
Thanks,
Thomas
Packet loss (IPv4 & IPv6)
If the problems persist, is it possible to switch to another PoP?
You are pinpointing this on the PoP, while none of the other users have this issue.
As you state yourself "Everything outside my network is not under my control", the same from our side and as other users do not have problems, and our measurements from various places do not show any either, we do not believe it is the PoP.
|
![[ch]](/s/countries/ch.gif)
on Thursday, 11 April 2013 09:41:52
Posting is only allowed when you are