Könntest du ggf. einen MTR zu IPv4 und IPv6 eines Servers von selben Anbieter machen?
Zum Beispiel:
v4: 108.61.210.117 v6: 2001:19f0:6c00:8002:5400:ff:fe00:536a
https://fra-de-ping.vultr.com/
Von dort könntest du ggf. auch die IPv6 Adresse des Routers anpingen und somit einmal den anderen Weg prüfen.
Wie schon gesagt, so ein Test wäre noch einmal schön :).
Sollte sich ja dann in sauberen Trippy-Resultaten zeigen, zumindest wenn die Trippy-Messung, ohne zusaetzliche grosse Netzbelastung gemessen wurde, aber waere das eleganteste wenn der ISP das auf seiner Seite behoben hat, der Verdacht bestand ja, dass es ein ISP-seitiges Problem ist (auch wenn wir bis jetzt noch keinen harten Beweis dafuer haben).
Werde ich später mal testen, wenn ich zuhause bin.
Die offizielle Empfehlung von MS ist die IPv6 Unterstützung aktiviert zu lassen!
Das ist logisch und bekannt.
Damit hast du einer Netzwerkkarte die IPv6 Adresse geklaut, bist aber weit davon entfernt, IPv6 im System deaktiviert zu haben. Je nachdem, welche Dienste nun für die IPC oder auch für externe Kommunikation IPv6 nutzen wollen, hast du dir damit ein sehr gründliches Problem geschaffen.
Nein, man hat sich kein Problem geschaffen, sondern das System nutzt einfach kein IPv6 mehr.
Wenn man IPv6 nicht nutzen will, weil es von Provider-Seite aus nicht funktioniert, gibt es andere Methoden, die mit weniger Nebenwirkungen zum Ziel führen.
Nein. Das deaktivieren von IPv6 in den Einstellungen des Netzwerkadapters ist die beste Option für solch ein einzelnes Gerät.
Bei einer FritzBox könnte man noch IPv6 für das gesamte Heimnetz deaktivieren.
Nein, man hat sich kein Problem geschaffen, sondern das System nutzt einfach kein IPv6 mehr.
Was schlicht Unsinn ist, da ja alle anderen Netzwerkadapter (inkl. localhost) noch über IPv6 Adressen verfügen.
Das deaktivieren von IPv6 in den Einstellungen des Netzwerkadapters ist die beste Option für solch ein einzelnes Gerät.
Wenn man wirklich sicher verhindern will, dass ein Gerät über IPv6 kommunizieren will, dann stimmt das nicht.
Bei einer FritzBox könnte man noch IPv6 für das gesamte Heimnetz deaktivieren.
In dem Moment, wo IPv6 auf Provider-Ebene nicht funktioniert, wäre das der bessere Weg. Was nützt es einem, wenn dann ein einzelnes Gerät auf IPv6 verzichtet, aber alle anderen ihre Pakete immer noch ins Nirvana schicken?
ULA nicht gleich GUA. IPv6 kann im Heimnetz selbst dann sinvoll sein, selbst wenn der ISP nur IPv4 liefert.
Was schlicht Unsinn ist, da ja alle anderen Netzwerkadapter (inkl. localhost) noch über IPv6 Adressen verfügen.
unsinn ist das natürlich nicht.
Selbstverständlich muss man IPv6 bei allen LAN/WLAN Adaptern deaktivieren, die mit dem problematischen Netzwerk verbunden sind.
Andere virtuelle Netzwerkadapter sind uninteressant und haben dann auch kein IPv6, außer über IPv4 Tunnel und das geht dann ja am IPv6 Problem des Providers vorbei.
Wenn man wirklich sicher verhindern will, dass ein Gerät über IPv6 kommunizieren will, dann stimmt das nicht.
das ist falsch.
IPv6 im Netzwerkadapter der mit dem Heimnetz verbunden ist aus -> keine IPv6 Verbindung mehr über das Internet-Providernetzwerk.
In dem Moment, wo IPv6 auf Provider-Ebene nicht funktioniert, wäre das der bessere Weg. Was nützt es einem, wenn dann ein einzelnes Gerät auf IPv6 verzichtet, aber alle anderen ihre Pakete immer noch ins Nirvana schicken?
natürlich ist das deaktivieren von IPv6 für ein einzelnes Gerät nur ein erster Test ob das Problem damit gelöst ist.
Es gibt auch Router, die kein deaktivieren von IPv6 für das Netzwerk zulassen, dann bleibt nur die Deaktivierung bei den einzelnen Geräten, sofern überhaupt möglich.
Oder Zwischenschaltung eines anderen Routers, der die Deaktivierung von IPv6 zulässt.
Tja, Schade aber auch. Hab das dem ISP so durchgegeben und die meinten, eine Problemstelle konnte die schon beseitigen und den Rest würden die auch noch hinbekommen.
Also weiter warten 
Ich weiss, das ist etwas frustrierend wenn es so hakt, aber zumindest redet Dein ISP mit Dir! Mit etwas Glueck laesst sich das wieder hin-biegen 
Provider meint ist behoben, WINMTR sagt was anderes.
Das ist voll OK, ausser, dass 19 Samples zu wenig ist. Zwischenhops arbeiten oft mit ICMP Ratenlimits und verwerfen ein paar bis alle Deiner Probes (hier Hop 3 und 8 ) auf die sie selber Antwortpakete generieren muessten, das ist ganz normal. Ein echtes Problem zeigt sich wenn ab Hop N alle weiteren Hops aehnlich hohen Pakezverlust zeigen. Aber hier ist der Verlust am Endziel 0%, also alles OK. Aber mach doch noch mal einen Test mit 1000 samples, weil bei 0.1-0.2% Verkustrate ist die Wahrscheinlichkeit das mit 19 Samples zu sehen recht gering.
Das ist voll OK, ausser, dass 19 Samples zu wenig ist. Zwischenhops arbeiten oft mir ICMP Ratenlimits und verwerfen ein paar bis alle Deiner Probes (hier Hop 3 und
auf die seie selber Antwortpakete generieren muessten, das ist ganz normal. Ein echtes Problem zeigt sich wenn ab Hop N alle weiteren Hops aehnlich hohen Pakezverlust zeigen. Aber hier ist der Verkust am Endziel 0%, also alles OK. Aber mach doch noch mal einen Test mit 1000 samples, weil bei 0.1-0.2% Verkustrate ist die Wahrscheinlichkeit das mit 19 Samples zu sehen recht gering.
Die gleiche Antwort habe ich auch vom ISP bekommen. Ich teste mal beim gamen.
Das ist voll OK, ausser, dass 19 Samples zu wenig ist. Zwischenhops arbeiten oft mir ICMP Ratenlimits und verwerfen ein paar bis alle Deiner Probes (hier Hop 3 und
Zwar nicht ganz 1000 Samples, aber trotzdem:
Kann man das Problem als gefixed ansehen?
Wie hoch ist das Intervall mit welchem du getestet hat? Würde so 500 Sampels machen aber dann natürlich mit einem höheren Intervall.
Wie hoch ist das Intervall mit welchem du getestet hat? Würde so 500 Sampels machen aber dann natürlich mit einem höheren Intervall.
1,5 Sekunden
3% schätze ich nicht als gut ein.
Da die Verluste aber erst hinterm Netz des Providers auftreten, können sie auch ein Server Problem sein. Man bräuchte mehrere Vergleichsmessungen zu anderen Zielen, um beurteilen zu können, wo das Problem auftritt.
Sehe ich auch so, kann ja auch am DECIX liegen, würde auch IPv6 und Ziele wie Cloudflare(1.1.1.1), Google(8.8.8.8) und aws.amazon.com testen.
Kann man das Problem als gefixed ansehen?
Kannst Du bitte nochmal einen Test mit trippy machen? Vielelicht ueber Nacht mit -C 3600 (eine volle Stunde).
