Warum O2
Warenkorb
 Service
Frage

DSL / IPv6: packet loss + hohe Latenz an 2a02:3001::2df (zu dns11.quad9.net)

L
Rang

Moin,

 

habe seit Tagen (heute aber besonders schlimm) Probleme mit meiner IPv6-Verbindung. Besonders auffällig dabei ist 2a02:3001::2df - welcher sehr hohe Latenzen und hohen packet loss aufweist (siehe mtr).

MTR wurde von einem Computer gemacht, welcher per Kabel mit meinem Router verbunden ist.

Habe die Störung auch o2 gemeldet, aber das Ticket wurde nach ein paar Stunden einfach geschlossen, weil “Keine Störung vorhanden” ist.

Was tun?

 

 

host (2a01:c23:5d9c::...) -> dns11.quad9.net (2620:fe::fe:11)    2024-04-11T18:29:37+0200

                                                                    Packets               Pings

Host                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev

1. fritz.box                                                      0.0%   150    1.6   1.3   0.9   2.7   0.3

2. 2a02:3001::23f                                           0.0%   150   47.0  75.7   6.8 1056.  84.7

3. 2a02:3001::2df                                         46.7%   150  1019. 2215.   6.6 7304. 2829.

4. 2a02:3001::1ae                                          0.0%   150    7.5   6.8   5.7  12.7   1.0

5. (waiting for reply)

 

Bei IPv4 scheint alles in Ordnung zu sein:

 

host (192.168.91.2) -> dns11.quad9.net (9.9.9.11)                            2024-04-11T18:37:07+0200

                                                                    Packets               Pings

Host                                                             Loss%   Snt   Last   Avg  Best  Wrst StDev

1. 192.168.91.1                                              0.0%    50    1.0   1.1   0.8   1.7   0.2

2. 62.52.201.185                                            0.0%    50    6.3  10.0   5.9  46.9   9.3

3. 62.53.2.84                                                  0.0%    50    6.9   6.9   6.1   9.5   0.5

    62.53.2.94

4. 62.53.11.127                                               0.0%    50    5.9   6.4   5.5   9.8   0.7

    62.53.11.125

5. (waiting for reply)

 

 



Das MTR wurde erstellt mit “mtr -T -6 dns11.quad9.net” (also über TCP, weil ICMP ja gerne von Routern verworfen wird unter Last.

 

Wo kann man das melden?

 

8 Antworten

P
Rang

Nirgendwo… Kein Zwischenhop schuldet Dir eine Antwort, weder fuer ICMP Echo Requests noch fuer versuchte TCP Verbindungen… Aber ein Zwischenhop mit komischen Werten hat wenig diagnostischen Wert, inrteressant wird es wenn von einem bestimmten Hop an all weiteren Hops von einem Problem (also meist erhoehter Paketverlust oder erhoehte Latenz) betroffen sind.

L
Rang

>  Kein Zwischenhop schuldet Dir eine Antwort, weder fuer ICMP Echo Requests noch fuer versuchte TCP Verbindungen…

Also ein HOP ist meiner Auffassung nach mir schon eine Antwort schuldig, wenn ich versuche eine Verbindung zu dns11.quad9.net aufzubauen.

Denn wenn keine Verbindung aufgebaut wird, ist das ja gleich eines nichtfunktionierenden Internets. Das Problem existiert auch mit UDP - was noch viel frustrierender ist, da dort ja nicht retry’d wird. 

Fakt ist jedenfalls, dass ich seit Tagen frustrierende Verbindungs-Probleme habe, dass Verbindungen abbrechen. Sehr oft natürlich zum DNS aber auch normale TCP Verbindungen (slack hat sich heute 4x neu-verbinden müssen).

Oft habe ich auch “Safari kann diese Seite nicht öffnen weil die Adresse der Seite nicht bekannt ist” (oder wie auch immer der genaue Wortlaut lautet).

Für mich ist anhand dieser Symptome offensichtlich, dass hier ein Konnektivitätsproblem vorliegt. In Wireshark sind auch öfter mal TCP Retries, Out of Order Antworten etc. zu finden. Also teilweise kommen Antworten einfach super spät (oder im UDP Fall halt auch gar nicht) an. Da DNS ja primär über UDP agiert, führt das dann halt zur prominenten Safari-Seite.

Ob es jetzt an dem diesem Hop oder an anderen Hops liegt, kann ich natürlich nicht mit Sicherheit sagen, aber klar ist, dass ich Probleme mit Verbindungen habe.

P
Rang

>  Kein Zwischenhop schuldet Dir eine Antwort, weder fuer ICMP Echo Requests noch fuer versuchte TCP Verbindungen…

Also ein HOP ist meiner Auffassung nach mir schon eine Antwort schuldig, wenn ich versuche eine Verbindung zu dns11.quad9.net aufzubauen.

 

Der letzte, also dns11.quad9.net, wobei der jedoch moeglicherweise nur auf UDP DNS Anfragen antwortet (und ICMP Echo Requests)… aber Du hast 2a02:3001::2df als auffaellig beschrieben, und das ist ein normaler Zwischenhop...

 

 

Denn wenn keine Verbindung aufgebaut wird, ist das ja gleich eines nichtfunktionierenden Internets.

Nein, dass ein Zwischenhop, oft ein Router wohl bereit ist Deine Paket zu forwarden, aber selber keine TCP Verbindungen mit Deinem Rechner aufbauen will ist im Internet die Regel, nicht die Ausnahme.

 

Das Problem existiert auch mit UDP - was noch viel frustrierender ist, da dort ja nicht retry’d wird. 

Naja, da gilt das gleiche, der Zwischen-Hop duerfte Infrastruktur sein und kein Server...

Fakt ist jedenfalls, dass ich seit Tagen frustrierende Verbindungs-Probleme habe, dass Verbindungen abbrechen. Sehr oft natürlich zum DNS aber auch normale TCP Verbindungen (slack hat sich heute 4x neu-verbinden müssen).

 

Das glaube ich Dir sofort, ich sage nur die MTRs von oben sind da nicht wirklich hilfreich bei der Diagnose.

Oft habe ich auch “Safari kann diese Seite nicht öffnen weil die Adresse der Seite nicht bekannt ist” (oder wie auch immer der genaue Wortlaut lautet).

Für mich ist anhand dieser Symptome offensichtlich, dass hier ein Konnektivitätsproblem vorliegt. In Wireshark sind auch öfter mal TCP Retries, Out of Order Antworten etc. zu finden. Also teilweise kommen Antworten einfach super spät (oder im UDP Fall halt auch gar nicht) an. Da DNS ja primär über UDP agiert, führt das dann halt zur prominenten Safari-Seite.

Ob es jetzt an dem diesem Hop oder an anderen Hops liegt, kann ich natürlich nicht mit Sicherheit

sagen, aber klar ist, dass ich Probleme mit Verbindungen habe.

Ich kann das sagen, es liegt nicht an 2a02:3001::2df sonst haettest Du schon keine Antworten vom naechsten Hop 2a02:3001::1ae  mehr  bekommen, bzw. nur mit dem selben Loss wie bei Hop3.

L
Rang

Nein, dass ein Zwischenhop, oft ein Router wohl bereit ist Deine Paket zu forwarden, aber selber keine TCP Verbindungen mit Deinem Rechner aufbauen will ist im Internet die Regel, nicht die Ausnahme.


Das das die Ausnahme wäre stimmt… aber ich baue doch gar keine Verbindung mit dem Hop auf? Zieladresse im IP Paket ist ja weiterhin die von dns11.quad9.net - nur die TTL läuft ab. Weiß nicht wieso ein Router das als Verbindungsaufbau zu ihm selbst sehen sollte.

 

Ich kann das sagen, es liegt nicht an 2a02:3001::2df sonst haettest Du schon keine Antworten vom naechsten Hop 2a02:3001::1ae  mehr  bekommen, bzw. nur mit dem selben Loss wie bei Hop3.

Ergibt Sinn. Könnte ja aber auch sein, dass der Rückweg von hop 3 durchaus ein anderer ist, als der Hinweg, der paket loss aufweist. Wäre dann natürlich nicht die Schuld von Hop 3 selbst, aber dennoch ein Problem auf dem (Rück)pfad von Hop 3.

 

Das glaube ich Dir sofort, ich sage nur die MTRs von oben sind da nicht wirklich hilfreich bei der Diagnose.

Was wäre denn außerdem noch hilfreich zur Diagnose?

P
Rang

Nein, dass ein Zwischenhop, oft ein Router wohl bereit ist Deine Paket zu forwarden, aber selber keine TCP Verbindungen mit Deinem Rechner aufbauen will ist im Internet die Regel, nicht die Ausnahme.


Das das die Ausnahme wäre stimmt… aber ich baue doch gar keine Verbindung mit dem Hop auf? Zieladresse im IP Paket ist ja weiterhin die von dns11.quad9.net - nur die TTL läuft ab. Weiß nicht wieso ein Router das als Verbindungsaufbau zu ihm selbst sehen sollte.

 

Da hast Du wahtscheinlich recht ich hatte das mentale Model, dass MTR versucht zu allen Hops SYN Pakete zu senden, nur ist ein Router oft so konfiguriert, dass alles was nicht zum Kerngeschaeft Routing/Forwarding gehoert als Best Effort betrachtet wird, und dazu gehoert es Fehlermeldungen fuer TTL Exceeded zu versenden.

 

Ich kann das sagen, es liegt nicht an 2a02:3001::2df sonst haettest Du schon keine Antworten vom naechsten Hop 2a02:3001::1ae  mehr  bekommen, bzw. nur mit dem selben Loss wie bei Hop3.

Ergibt Sinn. Könnte ja aber auch sein, dass der Rückweg von hop 3 durchaus ein anderer ist, als der Hinweg, der paket loss aufweist. Wäre dann natürlich nicht die Schuld von Hop 3 selbst, aber dennoch ein Problem auf dem (Rück)pfad von Hop 3.

 

Ja assymetrische Pfade sind bnicht unueblich, aber hier sind Hop 3 und 4 beide im Netz von Telefonica (“mtr -ezb dns11.quad9.net” zeigt hilfreich MPLS Informationen an (muessen die MPLS nodes mitspielen) und die AS nummer, dann sieht man leicht wo die Hops beheimatet sind.)

 

Das glaube ich Dir sofort, ich sage nur die MTRs von oben sind da nicht wirklich hilfreich bei der Diagnose.

Was wäre denn außerdem noch hilfreich zur Diagnose?

Wie sieht es aus wenn Du statt Quad9 testweise die IPv6 DNS Server von O2 nimmst (also IIRC 2a01:c30::531)?

L
Rang

 

Nein, dass ein Zwischenhop, oft ein Router wohl bereit ist Deine Paket zu forwarden, aber selber keine TCP Verbindungen mit Deinem Rechner aufbauen will ist im Internet die Regel, nicht die Ausnahme.


Das das die Ausnahme wäre stimmt… aber ich baue doch gar keine Verbindung mit dem Hop auf? Zieladresse im IP Paket ist ja weiterhin die von dns11.quad9.net - nur die TTL läuft ab. Weiß nicht wieso ein Router das als Verbindungsaufbau zu ihm selbst sehen sollte.

 

Da hast Du wahtscheinlich recht ich hatte das mentale Model, dass MTR versucht zu allen Hops SYN Pakete zu senden, nur ist ein Router oft so konfiguriert, dass alles was nicht zum Kerngeschaeft Routing/Forwarding gehoert als Best Effort betrachtet wird, und dazu gehoert es Fehlermeldungen fuer TTL Exceeded zu versenden.

Fairerweise muss ich aber auch sagen, dass der Router ja keine DPI macht und dem glaub ich egal ist, was im IP Paket drin steht. TTL 0 → Paket weg. Die Antwort (auf die MTR ja trotzdem wartet) ist ja dennoch ICMP was der Router sich entscheiden kann nicht zu senden.

Ist dennoch etwas suspicious, dass von allen 3 o2 routern nur von einem keine pakete kommen - was ja evtl. auf hohe Last rückschließen könnte (vorausgesetzt, dass das eine Bedingung für das nicht-senden von ICMP Paketen ist).

 

 

 

Ich kann das sagen, es liegt nicht an 2a02:3001::2df sonst haettest Du schon keine Antworten vom naechsten Hop 2a02:3001::1ae  mehr  bekommen, bzw. nur mit dem selben Loss wie bei Hop3.

Ergibt Sinn. Könnte ja aber auch sein, dass der Rückweg von hop 3 durchaus ein anderer ist, als der Hinweg, der paket loss aufweist. Wäre dann natürlich nicht die Schuld von Hop 3 selbst, aber dennoch ein Problem auf dem (Rück)pfad von Hop 3.

 

Ja assymetrische Pfade sind bnicht unueblich, aber hier sind Hop 3 und 4 beide im Netz von Telefonica (“mtr -ezb dns11.quad9.net” zeigt hilfreich MPLS Informationen an (muessen die MPLS nodes mitspielen) und die AS nummer, dann sieht man leicht wo die Hops beheimatet sind.)

Okay - beim nächsten mal schaue ich, dass ich das MTR mit weiteren Flags mache.

 

 

Das glaube ich Dir sofort, ich sage nur die MTRs von oben sind da nicht wirklich hilfreich bei der Diagnose.

Was wäre denn außerdem noch hilfreich zur Diagnose?

Wie sieht es aus wenn Du statt Quad9 testweise die IPv6 DNS Server von O2 nimmst (also IIRC 2a01:c30::531)?

Wie gesagt, DNS ist der Fall, wo man es direkt merkt, aber es ist kein DNS Problem, denn Slack würde sich ja nicht neu verbinden, wenns nur DNS Problem wäre, denn dass löst ja einmal den Name auf beim Start und hält dann die Verbindung offen. Ich habe auch andere Browser-Fehler, wo zB manchmal auch keine SSL Verbindung hergestellt werden kann. Nach einem Reload funktionierts. Beides zusammen sagt mir, dass das kein DNS sondern ein Übertragungsproblem ist. Bei DNS fällts halt nur am häufigsten auf weil a) UDP und b) passiert das ja recht häufig wo es dann systembedingt halt auch direkt kracht (weil keine Antwort → keine Adresse → irgendwas funktioniert nicht).

 

 

P
Rang

Ist dennoch etwas suspicious, dass von allen 3 o2 routern nur von einem keine pakete kommen - was ja evtl. auf hohe Last rückschließen könnte (vorausgesetzt, dass das eine Bedingung für das nicht-senden von ICMP Paketen ist).

Jein, der ist halt so konfiguriert, bzw. dessen CPU mag ueberlastet/anderweitig mit wichtigerem beschaeftigt sein, aber die braucht er fuer seine Hauptbeschaeftigung Routing/Forwarding gar nicht. Hier mal mein Lieblingsdokument zum Thema Traceroute/mtr:

https://archive.nanog.org/sites/default/files/10_Roisman_Traceroute.pdf

Das enthaelt ganz gute Interpretationshilfen fuer Traceroute und Co..

 

Der Test mnit anderem DNS Server ist so leicht zu machen, dass ich empfehlen wuerde den trotz Vorbehalten einfach durchzufuehren, im Zweifel kannst Du mir ein “habe ich ja gleich gesagt, dass das nichts aendert” entgegenbringen ;)

o2_Steffen

Hallo und herzlich willkommen in der Community @layer8. 💙

Ich muss gestehen, dass ich mich mit dem ganzen Thema hier so gut wie gar nicht auskenne, daher bedanke ich mich schon einmal riesig bei pufferueberlauf0 für die tolle Unterstützung.

@layer8 hattest du den letzten Tipp zur PDF-Datei bereits durchführen können und hatte dies etwas gebracht?
LG Steffen

Du möchtest Tester oder Testerin werden um die aktuellsten Smartphones und Gadgets unter die Lupe zu nehmen? Wir suchen dich! => https://hilfe.o2online.de/testgeraete-8

Deine Antwort


Allgemeine Nutzungsbedingungen der O₂ Community
© Telefónica Germany GmbH & Co. OHG Telefónica