|
Ticket ID: SIXXS #1248618 Ticket Status: User PoP: deham02 - Easynet (Hamburg)
High Packet Los on IPv6 to POP
![[de]](/s/countries/de.gif) Shadow Hawkins on Thursday, 05 November 2009 08:34:02
Hello,
i established my Tunnel on Tuesday.
Since the beginning i have a high packet loss rate on the IPv6 connection.
The IPv4 connection to POP runs pretty fine.
IPv4:
sennfelder@yggdrasil:~$ traceroute 212.224.0.189
traceroute to 212.224.0.189 (212.224.0.189), 30 hops max, 60 byte packets
1 93.88.226.97 (93.88.226.97) 1.229 ms 1.216 ms 1.211 ms
2 sin-cr4.schnell-im-netz.de (62.180.65.131) 1.417 ms 1.417 ms 1.410 ms
3 schnell-im-netz-WUE.de.lambdanet.net (217.71.104.209) 4.503 ms 4.504 ms 4.499 ms
4 ge3-16.er11.ixfra.de.easynet.net (80.81.193.14) 5.949 ms 5.600 ms 5.914 ms
5 ge1-11.br2.isham.de.easynet.net (87.86.69.161) 18.772 ms 19.039 ms 18.782 ms
6 ge7-1.cr20.isham.de.easynet.net (212.224.4.89) 18.763 ms 18.856 ms 18.852 ms
7 212.224.0.189 (212.224.0.189) 18.841 ms 18.685 ms 18.430 ms
Here is the Output of MTR to 212.224.0.189:
Loss% Drop Rcv Snt Last Avg Best Wrst StDe
0.4% 547 15091 15145 18.8 15.0 14.7 1155. 7.2
MTR IPv6 to 2001:6f8:1c00:ee::1 :
Loss% Drop Rcv Snt Last Avg Best Wrst StDe
36.4% 5775 10102 15878 18.0 15.1 14.8 1240. 9.6
The tunnel is temporarily configured on an root server which is always on.
After the approval of a Subnet i want to switch the tunnel to my router @home
At the moment there is no Firewall between the server and the pop.
I have no idea what can cause this.
Kind Regards
Dominik
State change: user
The state of this ticket has been changed to user
High Packet Los on IPv6 to POP
And what exactly is the route over which this loss is happening?
High Packet Los on IPv6 to POP
Shadow Hawkins on Thursday, 05 November 2009 11:18:08
I'm not sure, that i understand what you mean.
The IPv4 Pings runs flawless, nearly no Packet loss to the POP IPv4 Address: 212.224.0.189
The IPv4 traceroute in the initial Ticket shows the route which is taken.
POPs IPv6 Address: 2001:6f8:1c00:ee::1
My IPv6 Address: 2001:6f8:1c00:ee::2
The loss happens direct at the first connection
The loss occurs already if i ping the 2001:6f8:1c00:ee::1
Hier are some tshark infos.
This looks like successful pings
6.129423 2001:6f8:1c00:ee::2 -> 2001:6f8:1c00:ee::1 ICMPv6 Echo request
6.147567 2001:6f8:1c00:ee::1 -> 2001:6f8:1c00:ee::2 ICMPv6 Echo reply
And this looks like the unsuccessful ones.
22.946167 2001:6f8:1c00:ee::2 -> 2001:6f8:1c00:ee::1 ICMPv6 Echo request
22.965885 212.224.0.189 -> 93.88.226.100 ICMP Destination unreachable (Port unreachable)
Dominik
High Packet Los on IPv6 to POP
I'm not sure, that i understand what you mean.
very simple: tracepath <ip address>
or for that matter: mtr --report -c 25 <ip address>
This as the packets get lost sometimes on the network and that is what you wrote in your original message, that there is packet loss.
The loss happens direct at the first connection The loss occurs already if i ping the 2001:6f8:1c00:ee::1
Thus there is most likely an issue with your tunnel.
22.946167 2001:6f8:1c00:ee::2 -> 2001:6f8:1c00:ee::1 ICMPv6 Echo request 22.965885 212.224.0.189 -> 93.88.226.100 ICMP Destination unreachable (Port unreachable)
And this indicates that the PoP doesn't have your tunnel configured.
And that can be because you have a heartbeat tunnel, and if your time is a bit off, then indeed your tunnel will sometimes work and sometimes won't.
High Packet Los on IPv6 to POP
Shadow Hawkins on Thursday, 05 November 2009 12:54:46
Hello Thanks for your help.
here the infos.
very simple: tracepath <ip address> or for that matter: mtr --report -c 25 <ip address>
sennfelder@yggdrasil:~$ tracepath 212.224.0.189
1: yggdrasil.sennfelder.de (93.88.226.100) 0.112ms pmtu 1500
1: 93.88.226.97 (93.88.226.97) 7.095ms
1: 93.88.226.97 (93.88.226.97) 6.418ms
2: sin-cr4.schnell-im-netz.de (62.180.65.131) 9.270ms
3: schnell-im-netz-WUE.de.lambdanet.net (217.71.104.209) 11.386ms asymm 4
4: ge3-16.er11.ixfra.de.easynet.net (80.81.193.14) 13.701ms asymm 6
5: ge1-11.br2.isham.de.easynet.net (87.86.69.161) 27.235ms asymm 9
6: ge7-1.cr20.isham.de.easynet.net (212.224.4.89) 22.474ms asymm 10
7: 212.224.0.189 (212.224.0.189) 27.995ms reached
Resume: pmtu 1500 hops 7 back 54
sennfelder@yggdrasil:~$ mtr --report -c 25 212.224.0.189
HOST: yggdrasil Loss% Snt Last Avg Best Wrst StDev
1. 93.88.226.97 0.0% 25 10.0 7.7 3.4 10.0 1.9
2. sin-cr4.schnell-im-netz.de 0.0% 25 10.5 8.5 4.1 14.9 2.2
3. schnell-im-netz-WUE.de.lambd 0.0% 25 14.4 11.5 7.5 15.1 1.9
4. ge3-16.er11.ixfra.de.easynet 0.0% 25 10.6 13.7 7.3 30.0 4.5
5. ge1-11.br2.isham.de.easynet. 0.0% 25 29.2 32.5 20.2 92.2 19.0
6. ge7-1.cr20.isham.de.easynet. 0.0% 25 29.7 25.7 18.7 34.9 3.2
7. 212.224.0.189 0.0% 25 35.3 25.7 19.1 35.3 3.2
This seems to look ok for me.
And this indicates that the PoP doesn't have your tunnel configured. And that can be because you have a heartbeat tunnel, and if your time is a bit off, then indeed your tunnel will sometimes work and sometimes won't.
Like i told this is a root Server in a data center.
I check the time:
sudo ntpdate pool.ntp.org
5 Nov 12:24:47 ntpdate[30680]: adjust time server 131.188.3.223 offset -0.000327 sec
This looks ok too.
Any other ideas?
Thanks in Advance for that.
High Packet Los on IPv6 to POP
This seems to look ok for me.
Then where is the problem?
Like i told this is a root Server in a data center.
What do you mean with 'root Server'? I am fairly sure you are not running any of the DNS root servers, these tend to have proper native IPv6 connectivity.
sudo ntpdate pool.ntp.org
Ever heard of this thing called ntpd that you keeps running in the background and updates time automatically?
Any other ideas?
As this is a problem report ticket and not a helpdesk. Nope.
There does not seem to be any problem. Now, if you encounter a problem, do properly report it, then we will spend time to actually look at it.
High Packet Los on IPv6 to POP
Shadow Hawkins on Thursday, 05 November 2009 13:24:09Then where is the problem?
AFAIK the Tunnel is established on the other side from the Maschine with IP 212.224.0.189 ?
So i'm wondering why ipv4 to this machine runs fine, but ipv6 not.
sennfelder@yggdrasil:~$ mtr --report -c 25 2001:6f8:1c00:ee::1
HOST: yggdrasil Loss% Snt Last Avg Best Wrst StDev
1. 2001:6f8:1c00:ee::1 32.0% 25 20.5 18.9 18.1 20.5 0.6
sennfelder@yggdrasil:~$ mtr --report -c 25 212.224.0.189
HOST: yggdrasil Loss% Snt Last Avg Best Wrst StDev
1. 93.88.226.97 0.0% 25 0.5 0.8 0.4 1.3 0.3
2. sin-cr4.schnell-im-netz.de 0.0% 25 0.6 1.1 0.5 3.8 0.7
3. schnell-im-netz-WUE.de.lambd 0.0% 25 3.7 4.9 3.5 17.6 2.8
4. ge3-16.er11.ixfra.de.easynet 0.0% 25 4.8 11.4 4.6 140.7 27.0
5. ge1-11.br2.isham.de.easynet. 0.0% 25 18.5 30.0 17.8 197.2 37.2
6. ge7-1.cr20.isham.de.easynet. 0.0% 25 17.8 26.6 17.8 215.5 39.4
7. 212.224.0.189 0.0% 25 18.9 18.8 18.2 19.3 0.3
Ever heard of this thing called ntpd that you keeps running in the background and updates time automatically?
Yes I surprisingly did, and its running in the background. Therefor the offset is only -0.000327 sec.
As this is a problem report ticket and not a helpdesk. Nope. There does not seem to be any problem. Now, if you encounter a problem, do properly report it, then we will spend time to actually look at it.
Sorry but i thought perhaps the problem is at the POP on the other side. Stupid me.
Thanks for your Help
High Packet Los on IPv6 to POP
So i'm wondering why ipv4 to this machine runs fine, but ipv6 not.
Maybe some node in the network between you and the PoP is 'rate limitting' or how they also like to call it "QoS" proto-41 packets? Not the first time we would see this happening.
> Ever heard of this thing called ntpd that you keeps running in the > background and updates time automatically?
Yes I surprisingly did, and its running in the background. Therefor the offset is only -0.000327 sec.
You can't run ntpd and ntpdate at the same time. Two reasons for this: ntpd would get clock-drift and it would thus get confused on how much to adjust, the second is more practical though:
box:~# ntpdate ntp.xs4all.nl
5 Nov 13:42:33 ntpdate[12213]: the NTP socket is in use, exiting
As such, you can't run both at the same time, as both require the use of local port 123, this as quite a few NTP servers only accept packets from that, and also except their responses there...
High Packet Los on IPv6 to POP
Shadow Hawkins on Thursday, 05 November 2009 14:12:42Maybe some node in the network between you and the PoP is 'rate limitting' or how they also like to call it "QoS" proto-41 packets? Not the first time we would see this happening.
Is it possible to test this in some kind?
You can't run ntpd and ntpdate at the same time. Two reasons for this: ntpd would get clock-drift and it would thus get confused on how much to adjust, the second is more practical though:
box:~# ntpdate ntp.xs4all.nl 5 Nov 13:42:33 ntpdate[12213]: the NTP socket is in use, exiting As such, you can't run both at the same time, as both require the use of local port 123, this as quite a few NTP servers only accept packets from that, and also except their responses there...
I'm running opentpd and the "ntpdate pool.ntp.org" was just once to see the offset at one.
And it works for me here "at the moment" like this.
sennfelder@yggdrasil:~$ ps xa | grep ntp
4217 ? Ss 0:00 /usr/sbin/ntpd
4218 ? S 0:00 /usr/sbin/ntpd
10541 pts/3 R+ 0:00 grep ntp
sennfelder@yggdrasil:~$ sudo netstat -tunap | grep ntp
udp 0 0 93.88.226.100:46615 141.40.103.102:123 ESTABLISHED 4218/ntpd
udp 0 0 93.88.226.100:55478 188.40.33.22:123 ESTABLISHED 4218/ntpd
udp 0 0 93.88.226.100:44729 141.40.103.101:123 ESTABLISHED 4218/ntpd
udp 0 0 93.88.226.100:37585 131.234.137.23:123 ESTABLISHED 4218/ntpd
sennfelder@yggdrasil:~$ sudo ntpdate pool.ntp.org
5 Nov 14:10:48 ntpdate[10548]: adjust time server 95.156.194.53 offset 0.001196 sec
High Packet Los on IPv6 to POP
Is it possible to test this in some kind?
Very hard, as the "QoS" generally kicks in when network links are getting "saturated" or whatever limit they configure, and then you don't know why it is happening. The only folks who can answer this are the ISPs on the complete path.
There is no mtr/smokeping with proto-41 mode thus very hard to see what is dropping packets and where. ICMP for that matter is because of that also 'just an indication' (there are enough setups which per default prioritize ICMP so that your "latency is always low")
I'm running opentpd and the "ntpdate pool.ntp.org" was just once to see the offset at one.
Don't mix and match openntpd and ISC's ntpdate, NTP does not work that way.
You will get clock drift that neither ISC ntpd nor OpenNTPd likes. OpenNTPd clearly operates a bit differently so that ntpdate can't figure out if there is already a NTPd running in the background.
High Packet Los on IPv6 to POP
Shadow Hawkins on Tuesday, 10 November 2009 14:45:36
After the approval of my subnet i switched the tunnel to my Home Fritz.box
Now is i look at the stats of my tunnel i have to say it works like a charm. :)
got to figure out what happens on the other machine. :)
Thanks for your help.:)
|
![[ch]](/s/countries/ch.gif)
on Thursday, 05 November 2009 10:39:54
Posting is only allowed when you are