Solved

IPv6 Cloudflare Packet Loss (Telecom Italia (Seabone) Peering Schuld?)

6 years ago

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

 

 

 

 

1493

21

  • Accepted Solution

    accepted by

    6 years ago

    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.

    0

This could help you too

in  

1205

0

3

Solved

in  

15658

0

3

Solved

559

0

1

Solved

4 years ago

495

0

2

Popular tags last 7 days

Cookies and similar technologies

We use cookies and similar technologies (including ) on our website to save, read out and process information on your device. In doing so, we enhance your experience, analyze site traffic, and show you content and ads that interest you. User profiles are created across websites and devices for this purpose. Our partners use these technologies as well.


By selecting “Only Required”, you only accept cookies that make our website function properly. “Accept All” means that you allow access to information on your device and the use of all cookies for analytics and marketing purposes by Telekom Deutschland GmbH and our partners. Your data might then be transferred to countries outside the European Union where we cannot ensure the same level of data protection as in the EU (see Art. 49 (1) a GDPR). Under “Settings”, you can specify everything in detail and change your consent at any time.


Find more information in the Privacy Policy and Partner List.


Use of Utiq technology powered by your telecom operator


We, Telekom Deutschland GmbH, use the Utiq technology for digital marketing or analytics (as described on this consent notice) based on your browsing activity across our websites, listed here (only if you are using a supported internet connection provided by a participating telecom operator and consent on each website).

The Utiq technology is privacy centric to give you choice and control.

It uses an identifier created by your telecom operator based on your IP address and a telecom reference such as your telecom account (e.g., mobile number).

The identifier is assigned to the internet connection, so anyone connecting their device and consenting to the Utiq technology will receive the same identifier. Typically:

  • on a broadband connection (e.g., Wi-Fi), the marketing or analytics will be performed based on the browsing activities of consenting household members’.
  • on mobile data, the marketing will be more personalised, as it will be based on the browsing of the individual mobile user only.

By consenting, you confirm that you have permission from the telecom account holder to enable the Utiq technology on this internet connection.

You can withdraw this consent anytime via "Manage Utiq" at the bottom of this site or in Utiq’s privacy portal (“consenthub”). For more, see Utiq's privacy statement.