Hallo,
Ich und weitere Kunden der deutschen Telekom haben seit mindestens Mitte letzter Woche massive Probleme mit IPv6 zu Telekom-Anschlüssen. Wenn es garnicht gehen würde wäre das okay, aber es funktioniert, aber langsamer als ein 56k-Modem, und mit ständigen Verbindungsabbrüchen.
Speedtest von proof.ovh.net:
Traceroute von einem OVH Server in RBX:
Ich habe ca. 40 Server bei OVH verteilt in RBX, SBG und GRA stehen, und alle sind von dem Problem betroffen.
Es sieht so aus als wenn die Übergabe an seabone (2001:41a8:20:2::41) hier Probleme macht.
Kann jemand das Problem bestätigen? Falls ja, bitte ich darum ein Störungsticket zu eröffnen.
Ich bin seit 4 Tagen mit dem OVH Support am diskutieren, und OVH sieht nicht ein, dass ich den proof.ovh.net Server nicht in den Rescue-Modus fahren kann ... (Okay, ich soll meinen Server in den rescue modus fahren, was aber rein garnichts bringt, da das Problem alle Server betrifft und auch beim Download von proof.ovh.net auftritt).
Off-Topic: Für mich ist die Bearbeitung und das erfolgreiche Ignorieren des Problems jenes, welches das Fass zum überlaufen bringt. Habe noch mehr Störungstickets offen, bei denen das Problem nach langer Diskussion bestätigt, aber noch nicht gelöst wurde. OVH darf gerne ab nächstem Monat auf meine monatlichen 15.000€ verzichten. :mad:
Ich und weitere Kunden der deutschen Telekom haben seit mindestens Mitte letzter Woche massive Probleme mit IPv6 zu Telekom-Anschlüssen. Wenn es garnicht gehen würde wäre das okay, aber es funktioniert, aber langsamer als ein 56k-Modem, und mit ständigen Verbindungsabbrüchen.
Speedtest von proof.ovh.net:
Code:
hook@hook-kubntu:~$ wget -O /dev/null http://ift.tt/1IiFQsd
--2015-07-21 19:21:07-- http://ift.tt/1IiFQsd
Auflösen des Hostnamen »proof.ovh.net (proof.ovh.net)«... 2001:41d0:2:876a::1, 188.165.12.106
Verbindungsaufbau zu proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1048576 (1,0M) [application/octet-stream]
In »»/dev/null«« speichern.
30% [===============> ] 314.895 3,43KB/s in 53s
2015-07-21 19:22:00 (5,81 KB/s) - Verbindung bei Byte 314895 geschlossen. Erneuter Versuch.
--2015-07-21 19:22:01-- (Versuch: 2) http://ift.tt/1IiFQsd
Verbindungsaufbau zu proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 1048576 (1,0M), 733681 (716K) sind noch übrig [application/octet-stream]
In »»/dev/null«« speichern.
72% [++++++++++++++++=======================> ] 764.633 2,34KB/s in 97s
2015-07-21 19:23:39 (4,54 KB/s) - Verbindung bei Byte 764633 geschlossen. Erneuter Versuch.
--2015-07-21 19:23:41-- (Versuch: 3) http://ift.tt/1IiFQsd
Verbindungsaufbau zu proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 1048576 (1,0M), 283943 (277K) sind noch übrig [application/octet-stream]
In »»/dev/null«« speichern.
76% [++++++++++++++++++++++++++++++++++++++++> ] 798.311 3,74KB/s in 31s
2015-07-21 19:24:13 (1,05 KB/s) - Verbindung bei Byte 798311 geschlossen. Erneuter Versuch.
--2015-07-21 19:24:16-- (Versuch: 4) http://ift.tt/1IiFQsd
Verbindungsaufbau zu proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 206 Partial Content
Länge: 1048576 (1,0M), 250265 (244K) sind noch übrig [application/octet-stream]
In »»/dev/null«« speichern.
100%[+++++++++++++++++++++++++++++++++++++++++=============>] 1.048.576 3,35KB/s in 54s
2015-07-21 19:25:10 (4,50 KB/s) - »»/dev/null«« gespeichert [1048576/1048576]
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. vss-5b-6k.fr.eu 0.0% 5 0.6 0.8 0.6 1.1 0.0
2. rbx-g1-a9.fr.eu 0.0% 5 4.4 4.7 2.0 11.3 3.7
3. 2001:41d0::27e 0.0% 5 12.8 13.0 12.5 14.0 0.5
4. ???
5. 2001:41a8:20:2::41 0.0% 5 20.9 20.9 20.7 21.1 0.0
6. 2001:41a8:20:2::32 0.0% 5 25.5 24.2 22.6 25.5 1.0
7. 2003:0:1901:8318::2 0.0% 5 26.8 26.5 26.0 27.1 0.0
8. 2003:0:1901:8318::1 0.0% 5 25.7 25.9 25.7 26.4 0.0
9. ???
Es sieht so aus als wenn die Übergabe an seabone (2001:41a8:20:2::41) hier Probleme macht.
Kann jemand das Problem bestätigen? Falls ja, bitte ich darum ein Störungsticket zu eröffnen.
Ich bin seit 4 Tagen mit dem OVH Support am diskutieren, und OVH sieht nicht ein, dass ich den proof.ovh.net Server nicht in den Rescue-Modus fahren kann ... (Okay, ich soll meinen Server in den rescue modus fahren, was aber rein garnichts bringt, da das Problem alle Server betrifft und auch beim Download von proof.ovh.net auftritt).
Off-Topic: Für mich ist die Bearbeitung und das erfolgreiche Ignorieren des Problems jenes, welches das Fass zum überlaufen bringt. Habe noch mehr Störungstickets offen, bei denen das Problem nach langer Diskussion bestätigt, aber noch nicht gelöst wurde. OVH darf gerne ab nächstem Monat auf meine monatlichen 15.000€ verzichten. :mad:
0 commentaires:
Enregistrer un commentaire