Menu Toggle

Aktuelle Einschränkungen

  • Kabel Beeinträchtigungen aller Kabel-Dienste im Raum Flensburg
  • Mobil Es kommt zu Verzögerungen bei der Auslieferung von SMS, überregional/SMS Benachrichtigungen der Mailbox sind auch betroffen.
  • Mobil Es kommt zu Einschränkungen bei der Erreichbarkeit im 2G/3G/4G Bereich, als Nachwirkung der Störung von gestern.
  • MeinVodafone im Web: Selfservice MeinVodafone im Web Registrierung/Hinzufügen von Verträgen.
  • Mobil: Aktuell kann es zu Einschränkungen, bei der Nutzung des Mobilen Hotspots bei iOS Geräten kommen.
  • Mobil: Bei Huawei Mifi Routern und Embedded Modulen, kann es zu falschen APN Einstellungen kommen. 

Nähere Infos dazu findest Du im Eilmeldungsboard.

Close announcement

Störungsmeldungen Internet, TV & Telefon Kabel

Siehe neueste

Probleme mit IPv6 Verbindungen bei vielen Anschlüssen

Highlighted
Netz-Profi

@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.

 

Mehr anzeigen
Highlighted
Netz-Profi
@Erik_Heinz
Dann hast du ein anderes Problem.
Mehr anzeigen
Highlighted
Smart-Analyzer

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.)

(1)
Mehr anzeigen
Highlighted
Smart-Analyzer

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.

(1)
Mehr anzeigen
Highlighted
Smart-Analyzer

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.

Mehr anzeigen
Highlighted
Smart-Analyzer

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? Smiley (zwinkernd)

 

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.

(1)
Mehr anzeigen
Highlighted
Moderatorin

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

Alles Easy How To Hilfe !
(1)
Mehr anzeigen
Highlighted
Smart-Analyzer

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 Smiley (fröhlich)

Mehr anzeigen
Highlighted
Netz-Profi
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.
Mehr anzeigen
Highlighted
Smart-Analyzer

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.

Mehr anzeigen