IPv6 geht nicht. Deutsche Glasfaser Support reagiert nicht

Zitat von fjen

Warum Umwege suchen, wenn der Anschluss das normalerweise bereitstellen soll?

Ja, das sehe ich auch so. Zumal die HE Lösung Nachteile bei der Latenz hätte, wenn sie funktionieren würde. Aber das scheidet ja von vornherein aus, wie @alfalfa ja schon richtig festgestellt hat.

Zitat von Kalle

Die IPv6 - Unterstützung der DG scheint sehr eigenwillig zu sein. Bei einem Kunden lief diese erst nachdem mir der Routerhersteller bintec elmeg eine Anpassung eingebaut hatte.

Ja, einen ähnlichen Fall hatten wir hier auch schon mal. Aber die Implementierung der DG mag ungewöhnlich sein, ist aber konform zu den RFCs. Deshalb sollten die Router damit umgehen können. Die meisten schaffen es ja auch.

Ich würde das jetzt nicht so pauschal sagen wollen, für mich sah das im letzten Jahr eher nach einer Nachlässigkeit in der Firmware von bintec-elmeg aus.

Zitat von frank_m

Deshalb sollten die Router damit umgehen können. Die meisten schaffen es ja auch.

Es gibt einige Hersteller, die dafür Anpassungen vorgenommen haben.

Ja. Deshalb: Specs immer vollständig lesen. Hat sich bewährt.

Zitat von fjen

Warum Umwege suchen, wenn der Anschluss das normalerweise bereitstellen soll?

Wie kommt man mit so einem Problem bei dem Support an die richtigen Leute? Der Support schlägt die üblichen Sachen wie Resets vor oder kommt mit einer Anleitung für Portfreigaben.

Gibt es in so einem Fall Anspruch auf Minderung der Rechnung? Ganz so einfach wie bei der neuen Bandbreiten Regelung kann man nicht kürzen.

Ticket erstellen und immer wieder drauf anrworreb

Bestenfalls täglich irgendwann hast du Glück wird es eskaliert dass du zur 2. Stufe der support Mitarbeiter kommst.

Der Fehler ist inzwischen wieder aufgetreten.

IPv6 Pakete werden ~3min nach letzten DHCPv6 renew/reply nicht mehr durchgeleitet.

Da die Leasetime 3600sek beträgt und nur alle 1800sek (T1 50%) ein DHCPv6 renew/reply durchgeführt wird, ist IPv6 damit praktisch nicht nutzbar.

Ein Client erzwungendes DHCPv6 renew alle z.B. 60sek führt dennoch nach ~3min zum Aussetzen der IPv6 Durchleitung.

Die Wartezeit bis zum nächsten "heilenden" DHCPv6 renew/reply wird zwar verkürzt, aber der Fehler bleibt bestehen, nach ~3min ist der IPv6 Aussetzer wieder da.

Hast du mal mit einem anderen Router getestet? Das Fehlerbild ist absolut einzigartig.

So ganz einzigartig wohl nicht, wenn schon 3 Personen das gleiche melden. Habe es selbst mit 2 Routern getestet, wenn auch vom selben Modell (FB 7590). Labor Firmware brachte auch keinen Unterschied. DG scheint da irgendwas am 28. Januar umgestellt zu haben.

Hatte noch eine 7270 hier. Mit der scheint das Problem innerhalb von 6 Stunden nicht aufzutauchen. Aufgrund des Alters aber keine Lösung.

Bei mir leider mit ffff:ffff

$ mtr -r -w -c 10 2a00:6020:1000:…
Start: 2022-02-20T23:13:44+0100
HOST:                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a03:4000:3e:166::2      0.0%    10    0.1   0.2   0.1   0.2   0.0
  2.|-- 2a03:4000:3e::2          0.0%    10    0.5   3.4   0.4  28.3   8.7
  3.|-- 2a00:11c0:47:3::32       0.0%    10    0.9   2.8   0.5  14.8   4.6
  4.|-- 2a00:11c0:47:1:47::139   0.0%    10    0.8   5.0   0.7  20.9   8.1
  5.|-- 2a00:11c0:47:1:47::141   0.0%    10    4.0   4.9   3.7   8.8   1.7
  6.|-- pr1.int63-fra.dg-w.de    0.0%    10    4.7   4.9   4.7   5.1   0.1
  7.|-- 2a00:6020:0:c::2        70.0%    10    5.1   4.9   4.7   5.1   0.2
  8.|-- 2a00:6020:ffff:ffff::14  0.0%    10    9.9   9.8   9.7  10.0   0.1
  9.|-- ???                     100.0    10    0.0   0.0   0.0   0.0   0.0

Zitat von fjen

So ganz einzigartig wohl nicht, wenn schon 3 Personen das gleiche melden.

Mag sein, ich würde aber trotzdem gern wissen, mit welchen Endgeräten das Problem auftritt. Vielleicht kann man daraus was ableiten.

fjen: so wie ich es interpretiere gibt es bei deiner getesteten Verbindung ein Problem zwischen Hop 7 und Hop 8. Eine Verdopplung der durchschnittlichen Ping-Zeiten ist schon ungewöhnlich.

Ich habe zwar nur ein traceroute6 von https://www.han.de/cgi-bin/nph-trace.cgi , da sieht es wie folgt aus:

Hop 4  pr1.int63-fra.dg-w.de (2001:7f8::eb86:0:1)  4.267 ms  4.263 ms  4.145 ms
Hop 5  2a00:6020:0:c::2 (2a00:6020:0:c::2)  4.521 ms  4.548 ms  4.407 ms
Hop 6  2a00:6020:ffff:ffff::12 (2a00:6020:ffff:ffff::12)  4.549 ms  4.427 ms  4.352 ms

Bitte beachte, das mein Hop 6 eine andere IP-Adresse hat, als dein 8..

Bei mir kann ich keine Auffälligkeiten bezüglich IPv6-Adressen erkennen.

Tja, ich habe leider wohl das gleiche Problem

IPv6 lief recht lange ohne Probleme, Jetzt funktioniert IPv6 (raus oder rein) nicht wenn der Lease etwas kleiner als 3300 ist.

Wenn ich einen neuen Lease erzwinge funktioniert es wieder für ca 5 Minuten, und dann erst wieder wenn der Lease bei 1800 ist und dann beim erneuten.

"Raus-Test": z.B. https://www.wieistmeineip.de/ipv6-test,
"Rein-Test" ist ein WIreguard-Server auf Raspberry-PI der vi Handy auf IPv6 angesprochen wird.

Mal sehen wie ich das in ein Ticket kriege, ich schau auch mal ob ich bei der FitzBox (FW 7.29) einen tcpdump bei den jeweiligen Zeitpunkten bekomme.

P.S. Bei mir ist der gleich Kreisrouter (".."ffff:ffff" ) im Spiel wie oben bei HubeBube (Hop 6)

Zitat von SpeedDevil

Tja, ich habe leider wohl das gleiche Problem

IPv6 lief recht lange ohne Probleme, Jetzt funktioniert IPv6 (raus oder rein) nicht wenn der Lease etwas kleiner als 3300 ist.

Hattet ihr nicht in Langenhain letzte oder vorletzte Woche eine Störung?

HubeBube: Hmm, die letzte die ich mitbekommen habe ist schon eher 4 Wochen her, war auch nicht nur Langehain betroffen (muss mal nach dem Ticket bei mir suchen). Allerdings ist unser Ausbau auch noch nicht abgeschlossen, zieht sich ganz schön hin.

Die Tage kann ich mal mit einem Nachbarn länger testen (zumindest das IPv6 rausgehend), da ist eine 7530 am laufen. Dank HomeOffice habe ich den Wireguard lange nicht gebraucht, letzte Woche das erste mal wieder ...


Ciao

Ich meine auch nicht den Stromausfall im Januar in Hünstetten von dem ein Teil der DG-Region betroffen war.

In der DG Störungsübersicht war Wochen später Langenhain vermerkt.

ich lese eigentlich zu dem Thema nur interessehalber, hab aber mal den Test aus dem Beitrag von SpeedDevil gemacht. Zeigt mir dies. Übrigens, bin bei DG, Tarif 400.

Ist dieses Tool aussagekräftig?

Der Tarif hat damit erst einmal nichts zu tun. Deutsche Glasfaser bietet dem Kunden ein Netz mit Dual Stack und CGN (Carrier Grade NAT). Damit erhälst Du eine IPv6-Adresse (eigentlich sogar ein ganzes IPv6 Netzsegment) und eine einzige IPv4-Adresse, die nicht öffentlich ist, d.h. außerhalb des DG Netzes unbekannt ist. Diese private IPv4 ADresse wird durch den Carrier (also DG) mittels Network Address Translation (NAT) in eine öffentliche verpackt. Das entspricht von der Technik dem ,was dein Router zu Hause macht, wenn die Geräte im Heimnetz über IPv4 mit anderen Geräten im Internet kommunizieren. Man spricht daher auch von "Doppel-NAT"

IPv6 bietet den Vorteil, das es weder ein normales noch ein "Doppel-NAT" geben muss. Daher ist die Latenz schon allein aus diesem Grund in IPv6 Netzen niedriger als bei IPv4 Netzen des Heimanwenders.

Durch das CGNAT haben die Endgeräte aber immer eine IPv4 und (mindestens) eine IPv6 Adresse. Daher ist es eine Störung oder Fehlkonfiguration oder Produktmangel wenn nur ein IP-Adresstyp am Endgerät sichtbar ist.

Kurzes Update, kleiner Test beim Nachbarn, nur Outgoing IPv6 getestet:
Das gleiche Verhalten wie bei mir, für rund 5 Minuten nach dem Lease funktioniert, danach erst mal nicht mehr.

Ist auch eine eigener Router, FritzBox 7530 mit FW 7.29

Da wir ja offensichtlich am gleichen Kreisrouter aber unterschiedlichen PoPs hängen ein aktueller traceroute6:

2a01:488:66::a5c:2478 (2a01:488:66::a5c:2478)  0.137 ms  0.121 ms  0.069 ms
 ae3.cr-vega.sxb1.core.heg.com (2a01:488:bb::52)  0.375 ms  0.262 ms  0.249 ms
 ae7.fra10-cr-antares.bb.gdinf.net (2a01:488:bb03:101::2)  3.153 ms  3.241 ms  3.147 ms
 pr1.int63-fra.dg-w.de (2001:7f8::eb86:0:1)  4.274 ms  6.311 ms  4.364 ms
 2a00:6020:0:c::2 (2a00:6020:0:c::2)  4.784 ms  4.537 ms  4.387 ms
 2a00:6020:ffff:ffff::12 (2a00:6020:ffff:ffff::12)  4.498 ms  4.367 ms  4.425 ms
 2a00:6020:1000: kundeneigene FB 7590 / 7.29 hinter NT  7.261 ms !X  7.628 ms !X  7.97 ms !X

Ich bin geneigt diese Störungen auf euren aktuell laufenden Ausbau zu schieben. Dabei gibt es natürlich Änderungen. In der Theorie ist das bei uns in Eppstein auch noch der Fall. Allerdings ist in 4 Ortsteilen der Ausbau so weit beendet, das die Straßen bereits asphaltiert sind und nur noch der namensgebende OT mit der Burg erschlossen werden muss. In dieser Angelegenheit gibt es allerdings noch keinen Fortschritt.