Massive IPv6-Probleme / PMTUD Black Hole bei VDSL 250 (Downloads hängen, Websites laden stark verzögert)
vor 3 Stunden
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
51
10
Das könnte Ihnen auch weiterhelfen
vor 7 Jahren
575
0
4
1362
0
7
vor 2 Jahren
285
0
6
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 3 Stunden
@ProfessorQuantum
Damit hier einer der Teamies des @Telekom hilft Team schnellstmöglich helfen kann:
Bitte in den Benutzerdaten die Felder „Kundennummer“ und „Handynummer“ ausfüllen.
Beim Klick auf dein Bild (Avatar) rechts oben gelangst Du über den Menüpunkt "Meine Einstellungen" an den richtigen Punkt " Kundendaten für den Kundenservice".
Beispiel:
Sollte keine Kundennummer vorhanden sein, alternativ z. B. 1234567890 verwenden 💡
Unter Handynummer bitte eine aktuell erreichbare Rufnummer hinterlegen.
Unter "weitere Informationen" ein möglichst großzügiges Zeit Fenster zwischen 07 & 23 Uhr, wann ein Rückruf gut passt.
(Das Zeitfenster sollte möglichst mindestens eine Stunde groß sein)
Halte für den Rückruf der Teamies bitte zur Authentifikation IBAN (letzte sechs Stellen) und Kundennummer bereit.
Sorge dafür das Anrufe von der 0800 330 1000 dich erreichen können 👍
Weitere Infos zur Authentifikation: https://www.telekom.de/hilfe/vertrag-meine-daten/meine-daten/kontakt-zur-telekom/abfrage-persoenlicher-daten
Gruß
Waage1969
P.S.: hilfreich wäre eine kurze Rückinfo nach Erledigung - Danke!
0
4
von
vor 3 Stunden
@fdi
würde mal so sagen, mich interessiert eher die Antwort der Teamies auf solche Beiträge 🤔
Gruß Waage1969
von
vor 3 Stunden
mich interessiert eher die Antwort der Teamies
@fdi
würde mal so sagen, mich interessiert eher die Antwort der Teamies auf solche Beiträge 🤔
Gruß Waage1969
Wir geben das an unsere Fachabteilung weiter und melden uns wieder bei Ihnen :-)
von
vor 3 Stunden
OK 🤣
Ich tippe mal auf die Peering -Floskel.
Uneingeloggter Nutzer
von
vor 2 Stunden
Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
@ProfessorQuantum
Da muss ich gleich lachen...
Hier mein Gegenbeweis, ist aber nur Magenta L also 100 Mbit/s
curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 566 100 566 0 0 7989 0 --:--:-- --:--:-- --:--:-- 8085
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 1166M 100 1166M 0 0 11.9M 0 0:01:37 0:01:37 --:--:-- 12.1M
Läuft also ohne Probleme und ohne Abbruch hier.
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen.
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Welcher Router kommt zum Einsatz?
2
von
vor 2 Stunden
Welcher Router kommt zum Einsatz?
Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
@ProfessorQuantum
Da muss ich gleich lachen...
Hier mein Gegenbeweis, ist aber nur Magenta L also 100 Mbit/s
curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 566 100 566 0 0 7989 0 --:--:-- --:--:-- --:--:-- 8085
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 1166M 100 1166M 0 0 11.9M 0 0:01:37 0:01:37 --:--:-- 12.1M
Läuft also ohne Probleme und ohne Abbruch hier.
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen.
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Welcher Router kommt zum Einsatz?
Router: Speedport Smart 4
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
von
vor 2 Stunden
@JuergenS1
Davon gibt es fünf verschiedene.
Uneingeloggter Nutzer
von
vor 2 Stunden
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Also kein Leitungsproblem mit deiner I-Net-Anbindung.
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Anscheint hat der IPV6 DNS-Server ein Problem; deswegen läuft der in meinem Router nicht,
bei VPN gibt es ein anderes Routing, darauf hat die Telekom eh keinen Einfluß.
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Hat dir die KI auch erklärt was ein Jitter ist, und hast du das verstanden?
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Eigentlich sollte man die MTU nicht ändern, nicht alles was technisch möglich wäre, kann auch jedes System umsetzen;
evtl. werden aus einem Datenpaket 2.
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
0 % Packet Loss zu Cloudflare
Hallo Telekom-hilft-Team, hallo Community,
ich beobachte an meinem VDSL-250-Anschluss (Tarif: MagentaZuhause XL, Router: Speedport Smart 4) seit einiger Zeit ein sehr störendes Phänomen:
Webseiten laden im Browser oft nur mit starker Verzögerung, und größere Downloads (z. B. Android Studio von den Google-CDNs, ca. 1,8 GB) brechen nach wenigen Sekunden ab oder frieren komplett ein (Chrome zeigt dauerhaft „wird fortgesetzt“).
Interessanterweise ist die physikalische Leitung absolut fehlerfrei. Ein Speedtest liefert hervorragende Werte (248 Mbps Down / 42.4 Mbps Up / 0 % Packet Loss zu Cloudflare).
Ich habe das Problem systematisch analysiert und konnte es eindeutig auf ein Path MTU Discovery (PMTUD) Black Hole im IPv6-Netz der Telekom eingrenzen. Sobald der Datenverkehr über IPv4 läuft (oder getunnelt über ein VPN ), läuft die Leitung mit maximaler Performance.
Hier sind die CLI-Diagnosedaten, die das Problem auf Protokollebene untermauern:
1. Der Beweis: IPv4 vs. IPv6 im direkten Vergleich (via curl)
Beim Versuch, Android Studio direkt über IPv6 herunterzuladen, bricht die Verbindung sofort nach der Weiterleitung auf das Google- CDN ab und friert bei 0 Bytes/s ein:
> curl -6 -L -o NUL "https://redirector.gvt1.com/edgedl/android/studio/install/2024.2.1.12/android-studio-2024.2.1.12-windows.exe"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 651 100 651 0 0 531 0 00:01 00:01 0
0 0 0 0 0 0 0 0 00:01 0
0 0 0 0 0 0 0 0 00:01 0
Download-Geschwindigkeit: 0 Bytes/s (Abbruch / Timeout)
Erzwinge ich denselben Download über IPv4 (-4) oder schalte ich ein VPN ein, läuft die Leitung absolut stabil mit maximaler Bandbreite:
# Über IPv4 gezwungen (ohne VPN ):
> curl -4 -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 18.37M 0 01:03 01:03 17.14M
Download-Geschwindigkeit: 19266193 Bytes/s (ca. 154 Mbit/s stabil)
# Über IPv6, aber mit McAfee VPN :
> curl -L -o NUL -w "Download-Geschwindigkeit: %{speed_download} Bytes/s\n" "[URL...]"
100 1.13G 100 1.13G 0 0 14.11M 0 01:22 01:22 14.23M
Download-Geschwindigkeit: 14802233 Bytes/s (ca. 118 Mbit/s stabil)
2. Das Routing-Problem (Jitter am 1. Telekom-Hop)
In der Routenverfolgung über IPv6 fällt bereits am ersten Gateway-Router der Telekom ("2003:0:8301:e000::1") ein massiver Latenzeinbruch und starker Jitter auf:
> tracert dl.google.com
Routenverfolgung zu dL.GOOGLE.cOM [2a00:1450:400a:1001::5d] über maximal 30 Hops:
1 1 ms 3 ms 8 ms [Lokaler Speedport]
2 304 ms 157 ms 6 ms 2003:0:8301:e000::1 <-- Telekom Gateway (Jitter bis 304ms)
3 * * * ...
3. Der Nachweis des PMTUD Black Holes via Ping MTU-Test
Um die MTU-Grenzen zu testen, habe ich Pings mit unterschiedlichen Paketgrößen über IPv6 an "redirector.gvt1.com" gesendet. Die Grenze liegt bei PPPoE-VDSL rechnerisch bei 1444 Bytes Nutzlast (1492 Bytes MTU):
Ping mit 1000 Bytes Nutzlast (Erfolgreich):
> ping -6 -l 1000 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=59ms (0% Verlust)
Ping mit 1444 Bytes Nutzlast (Grenzwertig, extrem hoher Jitter bis 228 ms):
> ping -6 -l 1444 redirector.gvt1.com
Antwort von 2a00:1450:400a:1000::66: Zeit=105ms / 228ms / 13ms (0% Verlust)
Ping mit 1460 Bytes Nutzlast (Erfordert PMTUD / Fragmentierung -> 100 % Verlust):
> ping -6 -l 1460 redirector.gvt1.com
Zeitüberschreitung der Anforderung. (100% Verlust)
Da der Ping bei Überschreiten der MTU-Grenze (1460 Bytes Nutzlast = 1508 Bytes IP-Paket) einfach lautlos im Timeout verschwindet und keine ICMPv6-Nachricht des Typs 2 ("Packet Too Big") an meinen Client zurückgeliefert wird, liegt hier ein klassisches PMTU Black Hole vor.
Da CDNs standardmäßig Pakete mit einer Größe von 1500 Bytes über IPv6 senden, verwirft das Telekom-Gateway diese stumm. Die Gegenseite erfährt nie, dass sie die MSS verringern muss, was die TCP-Verbindung einfrieren lässt.
Fazit & Bitte:
Lokale Fehlerquellen (PC-Hardware, Kabel, hausinternes Netz, DNS-Filter) wurden durch die erfolgreichen IPv4- und VPN -Gegenproben sowie den mehrfachen Hardwarewechsel vollständig ausgeschlossen. Das Problem liegt serverseitig bzw. im Routing-Backbone des Telekom IPv6-Netzes.
Vielen Dank und viele Grüße!
EDIT:
Das Problem scheint sporadisch aufzutreten. In den letzten 10 Minuten hat es Problemlos funktioniert, jetzt wieder nicht. Ich beobachte noch ein Paar Tage die Situation, dann melde ich mich noch mal.
Eigentlich war ich bei Cloudflare schon raus, die haben einfach Netzprobleme,
bekomme ich ein Routing rund duch die Welt funktioniert es,
läuft das Routing über England, der HOP ist einfach überlastet, selbst ne normale WEB-Seite braucht das 1-2Min für den Aufbau,
wenn die hinter Cloudflare versteckt ist.
1
von
vor 2 Stunden
Danke für die Antwort! Kurz zur Aufklärung der Missverständnisse:
- DNS: Ist völlig intakt. Die Namensauflösung klappt in Millisekunden, erst
der anschließende Datenstrom friert ein.
- MTU: Habe ich im System nicht geändert. Ich habe lediglich per ping -l
verschieden große Testpakete gesendet (Standarddiagnose).
- Jitter: Latenz-Schwankungen am ersten Telekom-Hop von 6 ms bis 304 ms sind
die lehrbuchdefinition von Jitter.
- Cloudflare: War nur der neutrale Speedtest-Referenzpunkt. Der eigentliche
Fehler betrifft Google-CDNs (gvt1.com).
Trotzdem untersuche ich weiter, und beobachte meine Internetverbindung über die nächsten Tag e mal genauer.
Lg
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von