Probleme mit IPv6 Verbindungen bei vielen Anschlüssen
maik0055
Mastermind
Mastermind
  • Welchen Vertrag hast Du? (z.B. Internet + Telefon 100)      CableMax 1.000
  • Welches Modem/ Router nutzt Du? (z.B. Hitron)  Vodafone Station von Arris / eigene FritzBox 6591  FritzOS 7.13/7.21
  • Nutzt Du ein Leih-Gerät von uns oder hast Du ein eigenes Gerät?    beides - überwiegend die eigene 6591.  aktuell das Leihgerät
  • Welcher Fehler tritt auf? zu wechselnden IPv6 Adressen keine Verbindungen / Traceroute läuft ins leere Sigate Telefonie Probleme / Webseiten laden nicht, verzögert, langsam
  • Wie ist Dein Endgerät mit dem Modem verbunden? PC per Gigabit LAN, Macbook und Smartphone mit 5GHz WLAN ac
  • Welchen Browser verwendest Du normalerweise? Firefox, Chrome, ...
  • Welches Betriebssystem hast Du auf Deinem Rechner? Windows 10, MacOS, Android 10
  • Beginn und Zeitraum der Störung bereits seit Monaten, täglich sporadisch
  • Lade dazu noch einen Screenshot von den Signalwerten hoch. Diese findest Du in der Benutzeroberfläche Deines Kabelrouters über 192.168.0.1 bzw. über 192.168.178.1 bei der Fritzbox.
  • Welche Maßnahmen wurden durch die Störungshotline (erreichbar unter 0800-5266625) durchgeführt? Hotline kontaktiert und auch viele EMails bzgl. des Problems mit einem Techniker ausgetauscht, das letzte von vielen Tickets dazu ist seit Ende MAI(!) offen
  • In welchem Bundesland wohnst Du? Niedersachsen

 

Ich habe immer wieder Probleme mit IPv6. Der Anschluss läuft mit vollem DualStack also öffentlicher IPv4 + IPv6.

Probleme habe ich nur wenn am Router/Endgerät IPv6 zusätzlich mit aktiviert ist.

 

Problem ist zum einen, dass jedes x-te ausgehende Gespräch über Sipgate nur einseitig ist, dabei höre ich dann immer den angerufenen, er mich aber nicht.

Dieses Problem habe ich nur, wenn ich Sipgate auf IPv6 aktiviere über IPv4 keine Probleme.

Problem hatte ich schon an Sipgate gemeldet, die haben dort alles nachgeprüft und es gingen bei den problematischen Telefonaten Sprachdatenpaktete raus und rein, somit hat man mich an meinen Internetanbieter verwiesen.

 

Dazu kommt noch das Problem, dass Webseiten nicht/nicht vollständig oder nur sehr langsam/deutlich verzögert geladen werden.
Dies betrifft nur Webseiten, die zumindest in Teilen auch über IPv6 erreichbar sind.
Mit Webseiten, die ausschließlich über IPv4 erreichbar sind gibt es keine Probleme.

 

Youtube lädt oft lange/schlecht/nur teilweise.

Auch der Empfang/Versand von medien über Whatsapp ist oft schwierig.

 

Am Smartphone äußert es sich z.b. dadurch, das im Feed der Google App Bilder nicht geladen werden, oder sogar nicht mal das Feed vollständig.

Tippe ich in der GMail App auf einen Link wartet es auf die Weiterleitung über Google. Das auch gern mal 30+ Sekunden.

Tippe ich erneut auf den Link lädt die Seite meist sofort.

 

Ich habe, mit der FritzBox 6591 schon andere DNS Server ausprobiert und für IPv4+IPv6 eingerichtet.

Google DNS, Quad9, One.One.One.One - aber ohne Erfolg.

 

Schalte ich in der FritzBox IPv6 aus (für das Android Smartphone und alle anderen Geräte), bzw. am PC nur für den PC das IPv6 Protokoll deaktivieren, dann sind alle Probleme weg.

 

Ich hatte bereits im (inoffiziellen!) Vodafone Kabelforum dazu ein Thema erstellt worauf sich auch mehrere mit den selben Problemen gemeldet haben.

https://www.vodafonekabelforum.de/viewtopic.php?f=52&t=42580

 

Klar ist mittlerweile, dass das Problem nicht nur lokal bei mir ist und definitiv auch nicht hier im Haus seine Ursache hat.

Es muss ein Routing/Firewall Problem irgendwo im Vodafone Netz sein.

Auch im Ripe-Atlas ist deutlich bei Tests zu erkennen das ein großer teil der Testanschlüsse im Vodafone-Kabelnetz betroffen ist.

 

Gruß

maik0055

 
 
87 Antworten 87

@Erik_Heinz  schrieb:

Woher weißt Du, dass die Antwort auf dem Rückweg verloren geht?


Weil Sipgate das so analysiert hat (bei Gesprächen kann ich via IPv6 den Gesprächspartner sporadisch nicht hören.

 


@Erik_Heinz  schrieb:

Das Problem tritt  bei ALLEN IPv6-Zielen auf.


Dann hast du definitiv ein anderes aber ähnliches Problem, wo die Ursache auch woanders liegen könnte.

 

@Erik_Heinz
Dann hast du ein anderes Problem.

Zum Ursprungsproblem:

 

@vodafone Imho ist das ein kapputter LAG oder kapputtes ECMP/UCMP oder Ähnliches. Man sieht die Effekte des Flow Hashings in der Verteilung der Fehler.

 

Für die Laien:

 

Oft will man mehrere Möglichkeiten haben Daten zum gleichen Ziel zu bringen. Z.B. um sich gegen Ausfälle abzusichern. Wenn man die weiteren dann nicht nur als Backup sondern aktiv nutzt hat man auch eine gesteigerte Leistung. Dabei gibt es aber generell die Einschränkung das man einen einzelnen Datenstrom nicht über mehrere Möglichkeiten aufteilen will. (ZB weil das die Reihenfolge der Pakete ändern kann was bei UDP sehr schlecht für die Performance ist).

 

Daher ist es Standard Pakete die die gleichen Merkmale aufweisen dem gleichen Weg zuzuweisen. Ein beliebter Satz von verglichenen Merkmalen ist "Quell IP, Quell Port, Ziel IP, Ziel Port". Alle Pakete die dort die selben Werte habe laufen über den selben Weg. (Hin und Rückweg sind aber unabhänging und können unterschiedliche Wege nehmen)

 

Wenn nun einer dieser Wege kaputt ist ohne das man es merkt kommt es zu dem Effekt das einzelne Verbindungen scheinbar zufällig nicht funktionieren. (Vor allem da der Quell Port in der Regel zufällig ist.)

 

Um das zu testen habe ich in meiner FritzBox meinen Rechner komplett freigeschaltet und von Aussen TCP Portscanns durchgeführt. Dabei habe ich Quell IP, Quell Port und Ziel IP fest eingestellt. Den Ziel Port habe ich über 100 Ports variiert:

nmap -6 --source-port 10666 $myIP -d -p 20000-20100

Diese 100 Ports sind auf meinem Rechner alle geschlossen (D.h. nicht gefirewalled aber es läuft dort auch kein Programm). Mein Reschner schickt also eine entsprechende Meldung über TCP zurück (Reset). Gleichzeitig lief dort Wireshark um zu verifizieren das dort Packete ankommen.

 

Der Portscann leiferte allerdings einen Mischung aus "geschlossen" (d.h. Reset Empfangen) und "keine Antwort". Mehrere Weiderholungen zeigten die selben Ports im selben Zustand. Dann habe ich die Ziel Ports auf einige der "keine Anwort" Ports eingeschwänkt und Wireshark kontroliert. Im Gegensatz zu den vorherigen Scanns zeigte dieser keine empfangenen Pakete.

 

Dann habe ich den Quell Port auf 10667 umgestellt und den Scann über alle 100 Ziel Ports laufen lassen. Weider zeigte sich ein Muster aus geschlossen und keine Antwort. Diesmal aber ein anderes. Auch dieses war reproduzierbar. Wechselnde Wiederholungen zwischen den 2 Quell Ports zeigten dann immer "ihr" Muster.

 

Zuletzt habe ich das ganze von einem zweiten Rechner aus mit selbem Ergebniss (und 2 anderen Mustern) verifiziert.

 

Dies ist ganau das Ergebniss was man die dem Eingangs beschriebene Fehler erwarten würde. (Achtung es ist durchaus möglich das Wege nur in eine Richtung kaputt sind oder das nur eine Seite einen Ausfall mitbekommen hat.)

Auch ich habe das Problem seit Monaten. In der letzten Woche ist es jedoch schlimmer geworden.

 

Ich habe selbst einen Server auf dem ich testen kann. Jeder fünfte bis siebte Verbindungsaufbau (tcp) via IPv6 von Vodafone aus bleibt hängen. In den letzten Tagen häufig fast jeder zweite. Es ist dabei egal um welchen Dienst es sich handelt (ssh, imap, http) - alles tcp Verbindungen. Ob es udp auch betrifft, kann ich nicht sagen.

 

Das betrifft meinen Server und auch alle anderen IPv6 Internetdienste über tcp. Bei Openstreetmap z.B. merkt man es dann immer, wenn plötzlich die Kacheln weiss bleiben. Bei Internettelefonie, wenn die Verbindung abreißt. usw. usw.

 

Meine Beobachtung mittels tcpdump auf Client und Server beim Aufbau einer TCP Verbindung: der Client schickt ein SYN-SENT an den Server, dieser erhält das Paket (SYN-RECEIVED) und schickt daraufhin ein SYN/ACK-SENT zurück an den Client. Dieses Paket kommt dann allerdings am Client nie an und somit scheitert der Aufbau der Verbindung.

 

Sieht danach aus, daß beim Paketrouting etwas ins Nirvana läuft. (Vermutung - bin kein Netzwerkspezialist)

 

Da wir nun mal nativ an IPv6 hängen und immer mehr Dienste über IPv6 erreichbar sind, wird das Problem wohl von immer mehr Leuten bemerkt werden. Vodafone, da müsst ihr dringend Abhilfe schaffen. Und für die Ewiggestrigen: IPv4 wird ersetzt werden, IPv6 ist der Standard und muss auch funktionieren.

Ach bevor der Support mir nochn Strick draus drehn will:

Quelle isn Debian10 das mittels je 2 "eigener" Aristas und Mikrotiks am DFN hängt.

Ziel ein Debian11 mit Vodafone CableMax1000 an ner eigenen Fritzbox 6660.

Ich hab' jetzt auch noch mal ein bissl rumgetestet, da es heute extrem schlecht funktioniert hat. Ich habe Red Internet & Phone 50 Cable, bin z.Z. am AS3209, mit CH6640E Modem, DS-lite. Also absolut Vodafone Standard Anschluss ohne eigene Konfiguration und sollte doch damit laut Hotline-Weisheit problemlos funktionieren, oder? 😉

 

Getestet habe ich mit FreeBSD und Manjaro Linux als Clients bei mir zu Hause, sowie FreeBSD und Debian Linux als Server draußen im Netz.

Wie vorhin schon beschrieben betrifft es ausgehende IPv6 TCP Verbindungen, wenn die Antwort des Servers nicht mehr zurückkommt und dann die Verbindung hängen bleibt. Das zeigt sich dann beim Surfen, wenn die Seiten mittels IPv6 erreicht werden können (IPv6 wird vor IPv4 genutzt) oder, daß man halt z.B. mittels SSH, IMAP, SMTP, etc. nicht rauskommt. Ein Abbruch der Verbindung und neuer Connect funktioniert dann meistes. Das ganze ist unabhängig vom Betriebssystem.

 

Inspiriert durch thschmidts Schilderungen habe ich nun auch noch den anderen Weg getestet. Ich habe also am CH6640E die entsprechenden Ports freigegeben und mit SMTP und SSH von draußen auf meine Computer zu Hause zugegriffen. Dabei zeigte sich, dass hier auch ca. jeder sechste Verbindungsversuch nicht durchkommt. Pings waren aber generell NICHT betroffen. Pingen konnte ich immer problemlos. Es betraf nur TCP Verbindungen. Somit eignet sich der Ping auch nicht als Testinstrument für dieses Problem.

 

Das Fazit: eingehende TCP Verbindungen von außen ins Heimnetz mittels IPv6 funktionieren nicht immer.

Alle paar Mal kommt das Paket nicht durch, was zu weitreichenden Problemen führt.

Ob es sich dabei um eine Rückantwort auf eine nach draußen gerichtete Anfrage an einen Server im Internet oder einen direkten Zugriff aus dem Internet auf einen Server im Heimnetz handelt, ist dabei unerheblich.

Pings (ICMP Pakete) waren bei mir nicht betroffen, nur TCP Verbindungen.

 

Wie gesagt, das Problem besteht hier seit Monaten, Anfangs dachte ich, mein Serverprovider sei verantwortlich und hatte dort auch schon langes Hin und Her mit dem Support. Danach und nach meinen eigenen Tests kann ich mittlerweile eindeutig eingrenzen, daß es an meinem Anschluss bei Vodafone liegt.  Das Problem ist seit ein paar Tagen schlimmer geworden und tritt noch häufiger auf. Heute Nachmittag z.B. war fast jede zweite Verbindung betroffen.

Claudia
Ex-Moderator:in
Ex-Moderator:in

Hallo maik0055,

 

zu dem Thema stehst Du ja auch mit dem Fachbereich in Kontakt. Ich habe Deine letzten Erkenntnisse im Auftrag ***459/20 ergänzt.

 

Viele Grüße,

Claudia

Bewertet hilfreiche Beiträge mit Likes!

Ich kann die Probleme auch bestätigen und bin auf der Suche nach einer Lösung. Habe das Problem auch schon mehrere Monate, die bisherigen Beschreibungen und der angegebene Zeitraum in den anderen Beiträgen stimmen auch überein. Bei mir ist das Problem aber auf Android Smartphones (Galaxy S9 und S10) begrenzt. Alle Windows Laptops, iphones und Fernseher funktionieren einwandfrei.

 

Auf den Smartphones treten extrem lange Wartezeiten auf bis überhaupt etwas lädt. Nach ca. 30-60 Sekunden warten geht es dann plötzlich ganz schnell und die volle Bandbreite wird ausgenutzt (bis zu 100mbits)

 

Es muss doch irgendeine Lösung für das Problem geben auch wenn man kein IT-Experte ist sondern ein ganz normaler Student 🙂

Wenn alle Geräte außer den Android Smartphones funktionieren wird es vermutlich eine andere Ursache haben.
Welchen WLAN Router nutzt du?

Am PC ist IPv6 nicht deaktiviert?
Fernseher können je nach Alter gar kein IPv6.

Es hat sich was getan.

 

Das IPv6/UDP-Problem ist in meinen Messungen heute geringer - immernoch gehen deterministisch je nach Quell+Ziel IP+Port Pakete verloren, aber es sind jetzt nicht mehr 17%, sondern 8%

Auch IPv6/TCP Verbindungen brauchen jetzt nur noch halb so oft ein retransmit (wobei Google davon auch vorher nichr betroffen war, weil deren Traffic ueber einen anderen Router lief). Meine Messung zeigt jetzt, dass nur noch 8% der http-requests nicht in 1s fertig sind.

 

d.h. es funktionieren jetzt 11 von 12 Pfaden statt vorher 10 von 12.

Weiter so, liebes Vodafone team.