Probleme mit IPv6 Verbindungen bei vielen Anschlüssen
maik0055
IOT-Inspector
IOT-Inspector
  • 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

Danke für euer Feedback. Wir sind sehr zuversichtlich das Problem in Griff bekommen zu haben.


@Alex682  schrieb:

Danke für euer Feedback. Wir sind sehr zuversichtlich das Problem in Griff bekommen zu haben.


Wenn es diesmal dauerhaft und nicht nur 4 Wochen hält, wäre top.

@maik0055  schrieb:
Vom 10.06.2020 bis 13.07.2020 war das Problem bei vielen/allen(?) ganz plötzlich komplett verschwunden!
Leider kam das Problem am 13.07.2020 genauso plötzlich wieder wie es verschwand.

Ich hatte heute keinen Ausfall, aber der Router musste neu gestartet werden, damit das Problem verschwand.

 

Das einzige, was aktuell noch hakt ist der 2nd Google DNS, kann das jemand bestätigen? 

Kann aber auch sein, dass der "nur" Schluckauf hat.

 

@tt256 

Warum nur ein /64er Präfix?

 

@Herr_Knauer  : ich bin am Privatkunde am CBN CH6640E Modem von Vodafone und bekomme damit schon seit ich Kunde bin ein /64er. Kann man damit ein /56er bekommen?

 

@Herr_Knauer  :  meinst Du mit 2nd Google DNS ein anpingen des 2001:4860:4860::8844?

Ich kann beide Google DNS sowie beide Cloudflare DNS anpingen.

@tt256 

Bezüglich /64 Präfix muss ich mich wohl schämen, das geht AFAIK nur mit eigenem Endgerät.

 

Bei mir macht genau der DNS u.A. ping Spikes

Mehr anzeigen


--- --- --- --- ---
Your Input : 2001:4860:4860::8844
--- --- --- --- ---
2001:4860:4860::8844 Is Reachable via API (echo port 7)

Commandline ping result:
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=119 time=31.3 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=119 time=141 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=119 time=35.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=119 time=39.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=119 time=37.4 ms

--- 2001:4860:4860::8844 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4013ms
rtt min/avg/max/mdev = 31.382/57.052/141.107/42.115 ms

--- --- --- --- ---
Your Input : 2001:4860:4860::8844
--- --- --- --- ---
2001:4860:4860::8844 Is Reachable via API (echo port 7)

Commandline ping result:
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=119 time=37.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=119 time=199 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=119 time=29.5 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=119 time=32.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=119 time=36.9 ms

--- 2001:4860:4860::8844 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4015ms
rtt min/avg/max/mdev = 29.577/67.171/199.249/66.108 ms

--- --- --- --- ---
Your Input : 2001:4860:4860::8844
--- --- --- --- ---
2001:4860:4860::8844 Is Reachable via API (echo port 7)

Commandline ping result:
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=119 time=28.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=119 time=36.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=119 time=36.1 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=119 time=55.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=119 time=35.5 ms

--- 2001:4860:4860::8844 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4014ms
rtt min/avg/max/mdev = 28.258/38.443/55.431/9.040 ms

--- --- --- --- ---
Your Input : 2001:4860:4860::8844
--- --- --- --- ---
2001:4860:4860::8844 Is Reachable via API (echo port 7)

Commandline ping result:
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=119 time=28.0 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=119 time=30.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=119 time=28.5 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=119 time=141 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=119 time=34.7 ms

--- 2001:4860:4860::8844 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4016ms
rtt min/avg/max/mdev = 28.094/52.650/141.033/44.255 ms

@Herr_Knauer  :  ok, alles klar wg. des Präfixes.

und hier habe ich keine Spikes beim Anpingen:

 

Mehr anzeigen

ping -c 6 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=116 time=21.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=116 time=21.3 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=116 time=20.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=116 time=20.5 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=116 time=24.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=6 ttl=116 time=21.5 ms

--- 2001:4860:4860::8844 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 20.473/21.600/24.205/1.207 ms

ping -c 6 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=116 time=19.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=116 time=38.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=116 time=21.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=116 time=19.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=116 time=35.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=6 ttl=116 time=19.7 ms

--- 2001:4860:4860::8844 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 19.154/25.573/38.407/8.201 ms


ping -c 6 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=116 time=20.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=116 time=23.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=116 time=20.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=116 time=20.3 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=116 time=21.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=6 ttl=116 time=19.1 ms

--- 2001:4860:4860::8844 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 19.145/21.001/23.670/1.392 ms


und noch ein Langer:

ping 2001:4860:4860::8844
PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=116 time=18.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=116 time=24.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=116 time=21.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=116 time=20.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=116 time=22.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=6 ttl=116 time=19.0 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=7 ttl=116 time=22.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=8 ttl=116 time=20.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=9 ttl=116 time=20.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=10 ttl=116 time=19.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=11 ttl=116 time=21.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=12 ttl=116 time=19.3 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=13 ttl=116 time=21.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=14 ttl=116 time=19.0 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=15 ttl=116 time=20.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=16 ttl=116 time=21.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=17 ttl=116 time=20.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=18 ttl=116 time=23.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=19 ttl=116 time=19.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=20 ttl=116 time=21.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=21 ttl=116 time=24.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=22 ttl=116 time=19.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=23 ttl=116 time=20.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=24 ttl=116 time=22.2 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=25 ttl=116 time=22.5 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=26 ttl=116 time=21.9 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=27 ttl=116 time=19.7 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=28 ttl=116 time=20.5 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=29 ttl=116 time=38.0 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=30 ttl=116 time=24.4 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=31 ttl=116 time=20.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=32 ttl=116 time=20.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=33 ttl=116 time=20.8 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=34 ttl=116 time=21.3 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=35 ttl=116 time=18.6 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=36 ttl=116 time=19.1 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=37 ttl=116 time=19.1 ms
64 bytes from 2001:4860:4860::8844: icmp_seq=38 ttl=116 time=22.1 ms
^C
--- 2001:4860:4860::8844 ping statistics ---
38 packets transmitted, 38 received, 0% packet loss, time 37056ms
rtt min/avg/max/mdev = 18.632/21.480/38.037/3.127 ms

Ich werde das mit den Spikes mal weiter untersuchen.

 

Mein Test zeigt nun alle Ports als geschlossen so wie es sein soll.

 

Da mein Arbeitgeber durchweg Dual Stack hat musste ich die v6 vs v4 Präferenz auf v4 runterstellen um arbeiten zu können. Habe das nun wieder zurückgestellt und werd nächste Woche mal schaun wie's in der Praxis aussieht.

Na sieh mal an, kaum gibt es wohl eine Lösung werden den RIPE Network Coordination Centre Messpunkten im AS3209 Netz der Tag IPv6-Stable zugewiesen. (Beispiel Stand 08.11.2020) Das war ewig nicht der Fall. Das Stable-Tag gabs nur für IPv4. Im Beispiel ist ein Messpunkt der 90 Tage IPv4 Stable hat aber erst 1 Tag IPv6 Stable. 

 

Das Stable-Tag wird zugewiesen wenn: 

These tags indicate a level of stability and reliability beyond that signified by the "Capable" and "Works" tags (see above). In order for a probe to qualify for a Stable tag, it must have at least a 95% success rate for at least 95% of the time for the ICMP ping measurements that it performs. This means that occasional outages or connectivity problems are allowed so long as they are short and infrequent. The effects of widely unreliable or unreachable targets are controlled for by considering the success rate relative to measurements by other RIPE Atlas probes to the same targets.

 

Für diese Größe an Problem find ich es eine *Unverschämtheit* wie lange Vodafone rumgeeiert hat, Tickets immer wieder geschlossen hat (auch bei Business-Kunden) und das Problem nicht anerkennen wollte. Erst mit einem FORENBEITRAG - welcher laut AGB nichtmal ein akzeptierter Weg der Störungsmeldung ist - kam Bewegung in die Sache. Ich mein, dass die Hotline Mist ist, ist nichts neues.  Dennoch: Service? Setzen, sechs! Sorry. Insgesamt 7 Monate (was offiziell anerkannt wird, ich sag ja das ging noch länger zurück) Behebungszeit für ein deutschlandweites Problem, ist für einen ISP welcher die einzige Aufgabe hat mir einen stabilen Internetzugang zu liefern viel zu lang. Bedenkt man das man standardmäßig einen DS-Light Anschluss schaltet also IPv6 immer pref'd wird (und meinem Eindruck nach nach die AFTR-Gateways eher mager funktionieren und keinen sinnvollen Fallback bieten) - waren da sicherlich Millionen Kunden betroffen. 

 

Ich finde auch, nachdem die Community hier wochen- bis monatelang Einsatz gezeigt hat und mit kontinuierlichen, teils bidirektionalen Traceroutes und Ping-Probes zu verschiedenen Servern das Problem demonstriert hat und Netzwerk-Tickets bei betroffenen Diensten und im eigenen Unternehmen gefiled hat um Vodafone etwas Druck zu machen, etc. wäre ein öffentliches Postmortem sicher angebracht und verdient.

 

Das würde demonstrieren, dass Vodafone das Problem tatsächlich verstanden, Prozesse für die Zukunft optimiert und technische Probleme nachhaltig gelöst hat (und ihr nicht ab sofort bloß eure Core-Router alle 24h rebootet ;)).

 

Ist auch üblich in der Branche (siehe z.B. https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/) und wird von Kunden äußerst positiv betrachtet, wenn man zu Fehlern steht und zeigt, dass man sich verbessern will.


@philwo1  schrieb:

Ich finde auch, nachdem die Community hier wochen- bis monatelang Einsatz gezeigt hat und mit kontinuierlichen, teils bidirektionalen Traceroutes und Ping-Probes zu verschiedenen Servern das Problem demonstriert hat und Netzwerk-Tickets bei betroffenen Diensten und im eigenen Unternehmen gefiled hat um Vodafone etwas Druck zu machen, etc. wäre ein öffentliches Postmortem sicher angebracht und verdient.

 

Das würde demonstrieren, dass Vodafone das Problem tatsächlich verstanden, Prozesse für die Zukunft optimiert und technische Probleme nachhaltig gelöst hat (und ihr nicht ab sofort bloß eure Core-Router alle 24h rebootet ;)).

 

Ist auch üblich in der Branche (siehe z.B. https://blog.cloudflare.com/cloudflare-outage-on-july-17-2020/) und wird von Kunden äußerst positiv betrachtet, wenn man zu Fehlern steht und zeigt, dass man sich verbessern will.


WORD!

 

Es ist wirklich sehr gut, dass es nun endlich funktioniert. Der Verlauf zeigt in meinen Augen aber mehr als deutlich, dass Vodafone Kabel Deutschland noch sehr viel Potential hat den Service zu verbessern. Es bleibt fraglich, ob dieser Forumsbeitrag, die vielen Tickets und letztendlich die Behebung des Fehlers überhaupt so weit in die Führungsetage aufsteigen, dass jemand aufmerksam wird, der etwas ändern kann.

Bei der Bundeswehr wurden Fehlermeldungen auch jahrelang immer nur verwässert, wenn sie an die höhere Stelle gemeldet wurden. "Unten" war alles marode und "oben"  war man der Meinung, alles läuft bestens, es geht gar nicht besser. 

Von einem internationalen Telekommunikationskonzern erwarte ich mehr. 

Auf der anderen Seite muss VF KDG keine Konkurrenz fürchten. Entweder du nimmst deren Kabelprodukt oder gar keins... Da kann man sich derzeit drauf ausruhen. Irgendwann belebt FTTH/FTTB das ganze vielleicht wieder. Dann wird VF vielleicht nach Kurzarbeit und Subventionen rufen.

 

Aufwachen Vodafone!!! 🙂