Gelöst
IPv6 Cloudflare Packet Loss (Telecom Italia (Seabone) Peering Schuld?)
vor 6 Jahren
Hallo,
seite nun schon mehreren Wochen faellt mir auf, dass IPv6 Verbindungen zu Cloudflare (AS13335) aus dem Telekom Netz heraus mit viel Packet Loss verbunden sind. Zunaechst hier der traceroute, der zeigt, dass ueber Telecom Italia (Seabone) gerouted wird:
$ tracert -6 cloudflare.com Tracing route to cloudflare.com [2606:4700::c629:d7a2] over a maximum of 30 hops: 1 2 ms 3 ms 1 ms <ZENSIERT> 2 8 ms 8 ms 8 ms 2003:<ZENSIERT> 3 11 ms 14 ms 11 ms 2003:<ZENSIERT> 4 12 ms 11 ms 12 ms 2003:<ZENSIERT> 5 11 ms 11 ms 12 ms lo0.franco71.fra.seabone.net [2001:41a8:600::47] 6 15 ms 12 ms 12 ms 2001:41a8:600:2::19e 7 13 ms 12 ms 11 ms 2606:4700::c629:d7a2 Trace complete.
Verbindugngsversuche ueber IPv6 zu Cloudflare - also auch zu allen Websiten, die Cloudflare nutzen (was ja recht viele sind) - funktionieren wenig bis garnicht und wenn ueberhaupt dann nur sehr sehr langsam:
$ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out $ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out $ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out $ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out $ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out $ curl -6 -I cloudflare.com --connect-timeout 5 HTTP/1.1 301 Moved Permanently [..] $ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out $ curl -6 -I cloudflare.com --connect-timeout 5 curl: (7) Failed to connect to cloudflare.com port 80: Timed out
Eine schnelle Inspektion mit Wireshark zeigt sehr viele TCP Retransmissions - also Packet Loss.
Ueber IPv4 (und dementsprechend anderem Routing) ist das ganze kein Problem:
$ tracert -4 cloudflare.com Tracing route to cloudflare.com [198.41.215.162] over a maximum of 30 hops: 1 1 ms 2 ms 1 ms speedport.ip [192.168.2.1] 2 8 ms 8 ms 8 ms 62.155.246.42 3 11 ms 12 ms 11 ms 217.5.118.50 4 13 ms 11 ms 11 ms 62.157.249.186 5 13 ms 11 ms 12 ms ae-14.r24.frnkge08.de.bb.gin.ntt.net [129.250.4.10] 6 12 ms 12 ms 12 ms ae-8.r01.frnkge07.de.bb.gin.ntt.net [129.250.4.79] 7 12 ms 15 ms 13 ms 213.198.81.142 8 11 ms 12 ms 11 ms 198.41.215.162 Trace complete. $ curl -4 -I cloudflare.com --connect-timeout 1 HTTP/1.1 301 Moved Permanently [...] $ curl -4 -I cloudflare.com --connect-timeout 1 HTTP/1.1 301 Moved Permanently [...] $ curl -4 -I cloudflare.com --connect-timeout 1 HTTP/1.1 301 Moved Permanently [...] $ curl -4 -I cloudflare.com --connect-timeout 1 [...]
Nach meinen Experimenten kann ich jetzt folgendes sagen:
- Das ganze passiert mit allen Cloudflare Seiten
- Es ist immer ausschliesslich IPv6 betroffen
- Nicht-Cloudflare Seiten sind nicht betroffen
- Das Ganze ist absolut unabhaengig von der Tageszeit, den Packet Loss sehe ich frueh morgens, mittags, abends und spaet in der Nacht
- Packet Loss ist bei ICMPv6 nicht zu beobachten
- Das Problem tritt nicht auf bei Internetanschluessen von anderen Anbietern, lediglich Telekom-Anschlüsse scheinen betroffen zu sein
Daher wuerde ich jetzt spontan davon ausgehen, dass irgendwas auf der Route schief geht bzw. ueberlastet ist. Ist etwas Derartiges bekannt? Kann man das Problem irgendwie beheben?
Viele Gruesse
1486
21
Das könnte Ihnen auch weiterhelfen
vor 3 Jahren
1174
0
3
vor einem Jahr
624
0
5
vor 3 Jahren
1281
0
3
vor 6 Jahren
19
Antwort
von
vor 6 Jahren
Ich kann gerne nochmal auf das Problem genau hinweisen. Es besteht anscheinend bereits Packet Loss im Telekom Netzwerk wie man hier sieht (Hop 5): [...] Es werden wie bereits gesagt im Speziellen die TCP Syn Pakete beim Handshake scheinbar gedroppt und das wie gesagt schon im Telekom Netzwerk.
Ich kann gerne nochmal auf das Problem genau hinweisen. Es besteht anscheinend bereits Packet Loss im Telekom Netzwerk wie man hier sieht (Hop 5):
[...]
Es werden wie bereits gesagt im Speziellen die TCP Syn Pakete beim Handshake scheinbar gedroppt und das wie gesagt schon im Telekom Netzwerk.
Ja, so hatte ich das auch gemessen.
Um ehrlich zu sein ist es mir als Kunde aber auch egal ob das Problem im DTAG Netzwerk oder im Seabone Netzwerk auftritt. Letztendlich traegt die Telekom Verantwortung dafuer mit wem sie Peering betreibt.
Um ehrlich zu sein ist es mir als Kunde aber auch egal ob das Problem im DTAG Netzwerk oder im Seabone Netzwerk auftritt. Letztendlich traegt die Telekom Verantwortung dafuer mit wem sie Peering betreibt.
Sehe ich genauso. Die Analyse der Telekom kann nur einer abnicken, der genauso viel Ahnung hat wie der, der die "Analyse" hier gepostet hat. Unabhängig davon ist das Routing zumindest heute / gerade ein anderes (mtr zu cloadflare.com via tcp) - aber immer noch kaputt:
Host Loss% Snt Last Avg Best Wrst StDev
1. xxxxx 0.0% 42 0.5 0.5 0.3 0.7 0.0
2. yyyyyyyyy 0.0% 42 25.2 11.5 6.8 40.7 7.9
3. dtag-ic-319284-ffm-b4.c.telia.net 0.0% 42 10.2 10.6 10.1 11.4 0.0
4. ffm-b4-link.telia.net 57.1% 42 1010. 2738. 10.6 7027. 1877.
5. ffm-bb3-v6.telia.net 0.0% 42 11.1 10.6 10.0 11.4 0.0
ffm-bb4-v6.telia.net
6. ffm-b1-v6.telia.net 0.0% 41 11.4 11.5 10.3 23.8 1.9
7. cloudflare-ic-328337-ffm-b1.c.telia.net 0.0% 41 22.6 15.8 10.9 41.0 7.0
8. 2606:4700::c629:d7a2 0.0% 41 126.9 128.4 125.3 201.7 11.7
IPv6 scheint irgendwie auch zu anderen Zielen kaputt zu sein. download.asterisk.org ist da auch ein perfektes Beispiel. Via v4 -> fast 10 MByte/s beim Download. Via v6 irgendwas um die 200-300 kByte/s.
traceroute to downloads.asterisk.org (76.164.171.238), 30 hops max, 52 byte packets
1 * * *
2 xxxxxxxxxxxx 8.127 ms 8.163 ms 8.159 ms
3 was-sa2-i.was.us.net.dtag.de (62.154.5.194) 112.153 ms 112.161 ms 112.157 ms
4 80.157.130.154 (80.157.130.154) 107.301 ms 107.335 ms 107.333 ms
5 cer-edge-22.inet.qwest.net (205.171.139.18) 126.854 ms 126.884 ms 126.880 ms
6 63-233-99-114.dia.static.qwest.net (63.233.99.114) 129.674 ms 128.302 ms 128.788 ms
7 67.218.175.133 (67.218.175.133) 131.551 ms 131.622 ms 131.524 ms
8 static-76-164-170-13.apid.com (76.164.170.13) 132.839 ms 132.046 ms 131.910 ms
9 shooty.asterisk.org (76.164.171.238) 132.032 ms 132.592 ms 134.032 ms
Der ganze Spaß via v6:
traceroute to downloads.asterisk.org (2001:470:e0d4::ee), 30 hops max, 72 byte packets
1 x 0.298 ms 0.292 ms 0.350 ms
2 y 7.427 ms 7.457 ms 7.453 ms
3 dtag-as3320.100gigabitethernet11-2.core1.fra2.he.net (2001:470:0:45d::2) 9.937 ms 10.574 ms 10.805 ms
4 100gigabitethernet10-1.core1.fra2.he.net (2001:470:0:45d::1) 10.067 ms 10.066 ms 10.097 ms
5 e0-53.core1.ams2.he.net (2001:470:0:4b7::2) 16.313 ms * *
6 100ge8-1.core1.lon3.he.net (2001:470:0:227::1) 23.795 ms 23.216 ms 23.243 ms
7 100ge14-1.core1.lon2.he.net (2001:470:0:3ea::1) 21.858 ms 21.302 ms 21.550 ms
8 100ge13-2.core1.nyc4.he.net (2001:470:0:2cf::2) 102.871 ms 110.921 ms 110.883 ms
9 100ge16-1.core1.ash1.he.net (2001:470:0:299::1) 95.872 ms 94.699 ms 96.473 ms
10 tserv2.ash1.he.net (2001:470:0:90::2) 98.493 ms 98.435 ms 98.962 ms
11 tunnel46228-pt.tunnel.tserv13.ash1.ipv6.he.net (2001:470:7:4c2::2) 118.507 ms 121.087 ms 119.220 ms
12 2001:470:e0d4::ee (2001:470:e0d4::ee) 123.212 ms 121.675 ms 121.688 ms
=> Kurz vor Ende sogar noch ein Tunnel!
Für die nächsten ca. 10 Jahre kann man jedem nur raten, IPv6 abzuschalten bzw. so zu konfigurieren, dass es nur dann genutzt wird, wenn das Ziel keine v4-Adresse hat. Via Squid ist das über die Option dns_v4_first on möglich.
Antwort
von
vor 5 Jahren
Hallo,
habe gerade folgende Nachricht vom Cloudflare Support bekommen:
Just to update you, our engineering team have reached out to Deutsche Telekom for some debugging information, however they have been unresponsive to our requests. Without their cooperation, it will be difficult to resolve this issue. Sorry we can not be of more help at the moment. We can keep this ticket open for you if you wish and hopefully DTAG will cooperate with us soon.
Just to update you, our engineering team have reached out to Deutsche Telekom for some debugging information, however they have been unresponsive to our requests.
Without their cooperation, it will be difficult to resolve this issue.
Sorry we can not be of more help at the moment. We can keep this ticket open for you if you wish and hopefully DTAG will cooperate with us soon.
Was soll man da noch sagen...
Antwort
von
vor 5 Jahren
Hallo zusammen, die Frustration ist vollkommen verständlich. Prinzipiell ist zu sagen, dass unser Netz sowie das Peering fehlerfrei geprüft wurden. Dadurch das Cloudflare den Service in Italien hostet uns es dort zu Problemen kommt, könnte man zu den bereits bestehende Forum-Posts bei Cloudflare auch noch anbringen, dass die Telekom (AS3320) bereits fehlerfrei geprüft hat. Vielleicht hilft das den Kollegen weiter. Ich bedauere die eher negative Abschlussnachricht. Viele Grüße Nico B.
die Frustration ist vollkommen verständlich.
Prinzipiell ist zu sagen, dass unser Netz sowie das Peering fehlerfrei geprüft wurden.
Dadurch das Cloudflare den Service in Italien hostet uns es dort zu Problemen kommt, könnte man zu den bereits bestehende Forum-Posts bei Cloudflare auch noch anbringen, dass die Telekom (AS3320) bereits fehlerfrei geprüft hat.
Vielleicht hilft das den Kollegen weiter.
Ich bedauere die eher negative Abschlussnachricht.
Viele Grüße Nico B.
Kannst du bitte deinen Beitrag nicht als Lösung markieren? Das Problem ist nicht gelöst und Cloudflare versucht gerade aktiv, sich mit euch in Verbindung zu setzen um das Problem zu lösen.
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 6 Jahren
die Frustration ist vollkommen verständlich.
Prinzipiell ist zu sagen, dass unser Netz sowie das Peering fehlerfrei geprüft wurden.
Dadurch das Cloudflare den Service in Italien hostet uns es dort zu Problemen kommt, könnte man zu den bereits bestehende Forum-Posts bei Cloudflare auch noch anbringen, dass die Telekom (AS3320) bereits fehlerfrei geprüft hat.
Vielleicht hilft das den Kollegen weiter.
Ich bedauere die eher negative Abschlussnachricht.
Viele Grüße Nico B.
0
Uneingeloggter Nutzer
Frage
von