[Hook]

IPv6 zur DTAG wird nun direkt an die DTAG übergeben. Ich denke in Frankfurt.

 1. vss-5a-6k.fr.eu       0.0%    19   19.0 201.9   0.3 2007. 514.9
 2. rbx-g1-a9.fr.eu      88.2%    18    1.8   1.3   0.8   1.8   0.0
 3. 2001:41d0::27e        0.0%    18    8.2   8.2   8.0   8.5   0.0
 4. 2003:0:1306:8009::1   0.0%    18    8.0   9.8   8.0  26.6   5.1
 5. 2003:0:1901:8318::2   0.0%    18   12.0  12.1  11.7  13.7   0.3

2001:41d0::/32 -> OVH
2003::/19 -> DTAG

[fs80]

Also ich hatte am 27.07. eine Meldung auf mein Ticket bekommen, dass das Routing geändert wurde aber es hatte sich noch nichts verbessert und habe dann einen Trackert zu einem Kunden Anschluss geschickt und eine Antwort bekommen, das dieses an die Netzwerk Abteilung weitergegeben wurde. Habe von OVH noch keine Rückmeldung bekommen aber von 2 Kunden, das die Geschwindigkeit jetzt wieder gut sei und wenn die Route verfolge ist der Weg jetzt anders. Leider immer etwas schwer zu erkennen wie der weg geht, weil es ja bei ipv6 scheinbar kein Reserve DNS mehr gibt oder nicht gesetzt wird von den Providern.
Der Link zu dem Artikel würde mich auch interessieren.

[Hook]

IPv6 zur DTAG und zu anderen ISP's scheint wieder zu funktionieren. Mittlerweile auch wieder schneller besser als IPv4 (getestet mit einem 200MBit DTAG Glasfaser-Anschluss):
v4_ovh: 39.29 MBit
v6_ovh: 192.9 MBit
Habe dementsprechend IPv6 auch schon wieder aktiviert, Rückmeldung von OVH zu dem Thema fehlt aber noch.

Das war allerdings auch schon in der Presse

Kannst du mir mal einen Link dazu schicken?

[Caddy]

Ist das eigentlich noch aktuell? Ich wollte das gerade mal checken, kam aber zu diesem Ergebnis:
Roubaix 3:

wget -O /dev/null http://proof.ovh.net/files/1Gio.dat
--2015-07-31 07:36:04--  http://proof.ovh.net/files/1Gio.dat
Auflösen des Hostnamen proof.ovh.net... 2001:41d0:2:876a::1, 188.165.12.106
Verbindungsaufbau zu proof.ovh.net|2001:41d0:2:876a::1|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1073741824 (1,0G) [application/octet-stream]
In »/dev/null« speichern.

100%[=================================================================================================================================================================================================>] 1.073.741.824  102M/s   in 10s

2015-07-31 07:36:14 (102 MB/s) - »/dev/null« gespeichert [1073741824/1073741824]

GRA:

wget -O /dev/null http://proof.ovh.net/files/1Gio.dat
--2015-07-31 07:33:42--  http://proof.ovh.net/files/1Gio.dat
Resolving proof.ovh.net (proof.ovh.net)... 2001:41d0:2:876a::1, 188.165.12.106
Connecting to proof.ovh.net (proof.ovh.net)|2001:41d0:2:876a::1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1073741824 (1,0G) [application/octet-stream]
Saving to: `/dev/null'

100%[=================================================================================================================================================================================================>] 1.073.741.824 98,7M/s   in 11s

2015-07-31 07:33:53 (95,0 MB/s) - `/dev/null' saved [1073741824/1073741824]

Das ist natürlich OVH intern, ich kann aber auch die Probleme in den letzten Wochen bestätigen.
Zum IPv6 der DTAG möchte ich mal lieber nicht äußern, die haben nämlich ganz andere Probleme, für die wir mittlerweile die Kommunikation zur DTAG wieder auf IPv4 umgestellt haben und das nicht nur bei OVH. Das war allerdings auch schon in der Presse

[fs80]

Telekom direkt Traffic wird nicht günstig sein und da versucht man halt - über andere Wege - Geld zu sparen.

Denke es liegt nicht an den Traffic Kosten aber ipv6 scheint beim Routing noch nicht immer perfekt zu funktionieren. Ich habe mittlerweile die Server Kommunikation untereinander wieder auf ipv4 umgestellt, weil ich mehrmals sogar innerhalb des OVH Netzes Probleme hatte das immer mal wieder die Server mit ipv6 sich nicht mehr gefunden hatten was dann zu Verzögerungen führt bis der Server automatisch nach ipv4 auflöst.

[J-B]

100GBit Uplink heißt ja nicht das man diesen auch kostenlos voll ausnutzen kann.

Telekom direkt Traffic wird nicht günstig sein und da versucht man halt - über andere Wege - Geld zu sparen.

[denis]

Da hat OVH schon einen 100GBit Uplink zur Telekom, und dann nutzen die den nur für IPv4

[fs80]

Das Problem kann ich so bestaetigen, Server steht in RBX. Getestet gestern Abend.
Allerdings kann auch ich nicht in den Rescue Mode wechseln.

Das Problem kann ich bestätigen. Habe erst nur Mtr mit ipv4 gemacht, nachdem mich jetzt schon 4 Kunden angeschrieben haben, konnte aber keinen Fehler finden. Habe auch schon mit dem Support Tel. und die sagen es hätten sich sonst noch keine Kunden beschwert.
Ich habe jetzt einem Kunden einen ipv4 und ipv6 Link geschickt und die niedrige Geschindigkeit war nur beim ipv6 Link.

[Dragon]

Das Problem kann ich so bestaetigen, Server steht in RBX. Getestet gestern Abend.
Allerdings kann auch ich nicht in den Rescue Mode wechseln.

[Hook]

hast du keinen Server der im Moment nicht benutzt wird, um diesen im rescue zu starten?

Leider nein, da schon viele meiner Server nicht mehr bei OVH stehen.

Ich habe OVH nun mal vorgeschlagen, dass OVH mir für ein paar Tage einen Server stellt, den ich dann gerne in den rescue-Modus fahren kann.

Mit Support hat das alles aber nichts mehr zu tun. Aber für absolut miesen Support ist OVH ja sowieso schon bekannt.

[denis]

Netzwerkprobleme dem Support klarzumachen ist schwierig, die Erfahrung habe ich auch schon machen müssen.
Am besten ist man macht genau das, was die als Nachweis wollen.

hast du keinen Server der im Moment nicht benutzt wird, um diesen im rescue zu starten?

[Hook]

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:

hook@hook-kubntu:~$ wget -O /dev/null http://proof.ovh.net/files/1Mio.dat
--2015-07-21 19:21:07--  http://proof.ovh.net/files/1Mio.dat
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://proof.ovh.net/files/1Mio.dat
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://proof.ovh.net/files/1Mio.dat
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://proof.ovh.net/files/1Mio.dat
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]

Traceroute von einem OVH Server in RBX:

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

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.