Üblicherweise wird die Nachricht von weiteren Meldungen begleitet, wie DHCP Fehler oder ähnliche. Ist sowas zu sehen?
Kann ich nichts erkennen, oder?
Die Trennung der Internetverbindung lag jeweils daran, dass du keine gültige IP-Adresse mehr hattest. Um 14:43:58 ist die Lease abgelaufen (und konnte offenbar bis dahin nicht rechtzeitig erneuert werden). Um 16:14:06 wurde die Erneuerung vom DHCP-Server aktiv abgelehnt (nak = not acknowledged, nicht bestätigt).
Normalerweise läuft die Lease nur eine Stunde und der Client wartet auch nicht bis zum Ende sondern versucht lange vorher, die selbe Adresse beim bekannten Server zu erneuern. Wenn das nicht funktioniert, versucht der Client immer noch vor dem Ablauf der Lease, von irgendeinem DHCP-Server eine Adresse zu bekommen. Wenn das auch nicht funktioniert und die Lease abläuft, dann erst steht der Client ohne Adresse da. Bis dahin ist also schon einiges falsch gelaufen.
DHCP ist meiner Meinung nach bei der Deutschen Glasfaser eine Baustelle. Vielleicht arbeitet gerade mal jemand daran.
Bei den GK-Anschlüssen mit festen IP-Adressen/Netzen liegt die Leasetime bei 15 Minuten. Frage mich schon immer, was das soll!
DHCP ist meiner Meinung nach bei der Deutschen Glasfaser eine Baustelle. Vielleicht arbeitet gerade mal jemand daran.
Kann ich nur bestätigen! Siehe meine bezügliche Problembeschreibung im angehängten PDF. Bei Bedarf kann ich gerne auch noch die PacketTrace-Dateien (pcap), sowie FritzBox-Eventlog ergänzen. Und das war jetzt bereits das dritte Mal (so alle 2-3 Monate), dass ich stundenlang ohne IPv4- und/oder IPv6-Adressen dastand.
Habe das am 01.10.2022 an die DG per Mail geschickt. Antwort vom 03.10.2022:
"Unsere technische Abteilung hat Ihren Anschluss überprüft und konnte keine Unstimmigkeiten feststellen. Da Sie einen eigenen Router nutzen und wir auf diesen keine Übersicht haben, wenden Sie sich bitte an den Hersteller des Routers."
Diese Antwort war natürlich nicht akzeptabel. Auf meine weiteren Versuche am 03.10. und 18.10 erhielt ich bisher keine Antwort - die stellen sich taub.
Btw: Die Leasedauer ist für beide Protokolle jeweils eine Stunde. Die halbstündigen Renews (nach T1) werden im Eventlog der Fritzbox merkwürdigerweise für IPv6 gar nicht angezeigt und für IPv4 nur alle 12 - 12,5 Stunden.
Ergänzung: Ich denke, das Problem ist PLZ-unabhängig. Mein PLZ-Bereich ist 906xx.
Ergänzung2: Habe auch noch das EventLog der Fritzbox angehängt, das deren Kampf um IPv4- bzw. IPv6-Adressen widerspiegelt
Du schreibst in deinem einen Dokument, dass du ein DHCP-Offer für 10.124.1.24 bekommen hast. Das ist ja das völlig falsche Netz. Aus dem 10er Netz bekommen diejenigen eine IP, die im GPON Onboarding Prozess sind und den Aktivierungscode benutzen wollen. Bist du sicher, dass deine physikalische GPON Verbindung stabil stand zu dem Zeitpunkt?
Die Leasedauer ist für beide Protokolle jeweils eine Stunde. Die halbstündigen Renews (nach T1) werden im Eventlog der Fritzbox merkwürdigerweise für IPv6 gar nicht angezeigt und für IPv4 nur alle 12 - 12,5 Stunden.
Vielen Dank für deinen ausführlichen Problembericht und besonders für diesen Hinweis. Damit liest sich das Problem von Bracew genau wie deine Beschreibung.
dass du ein DHCP-Offer für 10.124.1.24 bekommen hast
von 10.124.1.24
Auch nicht besser. Den DHCP Offer bekommt man von einer 100er Adresse. Die MAC Adresse ist die gleiche, von der auch die IPv6 RAs kommen.
Für die DHCP Meldungen der Fritzbox scheint zu gelten, dass mindestens 12 Stunden und 1 Sekunde vergangen sein müssen, bevor eine neue Meldung im Log auftaucht. Wenn man Pech hat, ist die DHCP Transaktion zu früh fertig, und die nächste ist dann erst 30 Minuten später. Im Anhang ist ein Bild, wo ich mit grünen Pfeilen einige DHCP Updates mit 12 Stunden + 1 Sekunde markiert habe, und mit roten Pfeilen den Fall, wo sich die Sekunde nicht erhöht hat und folglich 12:30 seit dem letzten Eintrag vergangen sind.
Aber richtig ist, dass die alle 30 Minuten stattfinden. Bei DHCPv6 sind es alle 18,75 Minuten (1125 Sekunden, halbe Preferred Lifetime).
Ich hab den ganzen DHCP Traffic der DG schon mal ausführlich auseinandergenommen und auch die entsprechenden Wireshark Pakete gezeigt. Ich müsste den Post noch mal raussuchen. Aber eins ist sicher: 10er Adressen haben da nichts verloren. Deshalb ist mein Verdacht, dass schon lange vor DHCP was schief geht.
Das ist ja mal eine ausführliche Analyse! Ich befürchte nur, dass sich diese Analyse für 99,99 % der DGF Supportmitarbeiter wie Ägyptische Hieroglyphen liest!
Unsere Erfahrung mit 3 Business-Anschlüssen, die zuerst auch fehleranfällig waren, haben gezeigt, dass der Support so gut wie nichts kann und man den Punkt erreichen muß, an dem sich ein wirklich technisch versierter MA, der auch meistens nicht im Support angesiedelt ist, des Problems annimmt. Krönung war, bei einer Inbetriebnahme, 4 Wochen lang die Aussage, der Anschluß sei geprüft und in Ordnung, wir haben darauf die Lastschrifteinzüge zurückgeholt und danach kam heraus, dass die Glasfaser im Verteiler gar nicht gespleißt war!! Businessanschluß!!
Btw: Die Leasedauer ist für beide Protokolle jeweils eine Stunde. Die halbstündigen Renews (nach T1) werden im Eventlog der Fritzbox merkwürdigerweise für IPv6 gar nicht angezeigt und für IPv4 nur alle 12 - 12,5 Stunden.
Die absoluten Zeiten sind nicht in Beton gegossen oder in einem RFC manifestiert, lediglich das Verhältnis. Es obliegt der Firmenpolicy (und hoffentlich nicht den Befindlichkeiten eines Admins). Zumindest bei dem für mich zuständigen DHCP-Server von DG gab es im letzten Jahr eine Änderung, das die IPv6 preferred und valid lifetime nun identisch sind! Davor waren die Zeiten nicht gleich.
Nachtrag: Die Änderung war zwischen März und 04. Juli 2021, genauer kann ich das nicht mehr ermitteln. Seitdem werden valid lifetime (Startwert 3600 Sekunden) und preferred lifetime synchron heruntergezählt. Vorher stand valid lifetime in der Anzeige fix auf 3600 und lediglich die hintere Anzeige (preferred lifetime) verringerte sich. Aktuell sieht das so aus:
Internet -> Online-Monitor -> Internet, IPv6
IPv6-Adresse: 2a00:6020:1000:... Gültigkeit: 3544/3544s,
IPv6-Präfix: 2a00:6020:b398:.../56, Gültigkeit: 3544/3544s
Nach wie vor (zumindest so meine Beobachtung) wird nach der halben preferred lifetime (1125 Sekunden) ein DHVPv6 Renew an DG gesendet, da die Anzeige dann wieder auf 3600/3600s springt. Also kommt ein Reply von DG.
Du schreibst in deinem einen Dokument, dass du ein DHCP-Offer für 10.124.1.24 bekommen hast. Das ist ja das völlig falsche Netz. Aus dem 10er Netz bekommen diejenigen eine IP, die im GPON Onboarding Prozess sind und den Aktivierungscode benutzen wollen. Bist du sicher, dass deine physikalische GPON Verbindung stabil stand zu dem Zeitpunkt?
Sorry, das war ein Schreibfehler meinerseits: Richtig ist die Adresse 100.124.1.24. Werde das PDF gleich gegen eine korrigierte Fassung austauschen. Da zu dem Zeitpunkt parallel IPv6-Kommunikation stattfand, bin ich mir auch sicher, dass meine physische GPON-Verbindung stabil stand.
Ok, dann hat sich der Verdacht erledigt. Dann liegt es meines Erachtens an der DHCP Infrastruktur.
Aber richtig ist, dass die alle 30 Minuten stattfinden. Bei DHCPv6 sind es alle 18,75 Minuten (1125 Sekunden, halbe Preferred Lifetime).
Hier die T1/T2-Werte für DHCPv6 und DHCPv4, die ich erhalte:
Unsere Erfahrung mit 3 Business-Anschlüssen, die zuerst auch fehleranfällig waren, haben gezeigt, dass der Support so gut wie nichts kann und man den Punkt erreichen muß, an dem sich ein wirklich technisch versierter MA, der auch meistens nicht im Support angesiedelt ist, des Problems annimmt.
Das ist auch meine Intention - in meinen Anfragen bitte ich jedes Mal freundlich erneut darum, die Analyse zum 2nd-Level-Support weiterzuleiten. Vielleicht klappt's ja irgendwann.
Ok, dann hat sich der Verdacht erledigt. Dann liegt es meines Erachtens an der DHCP Infrastruktur.
Das sehe ich auch so, und ich meine, jeder Netzwerk-Spezialist, der sich mit Netzprotokollen auskennt und Paket-Mitschnitte lesen kann, sollte auch zu diesem Ergebnis kommen. Insofern danke für die Bestätigung hier im Forum!
Kaum zu glauben, aber wahr, ich hatte gestern die gleichen Meldungen im Log:
22.10.22 08:13:48 Internetverbindung wurde erfolgreich erneuert. IP-Adresse: 100...., DNS-Server: 185.22.44.50 und 185.22.45.50, Gateway: 100....
21.10.22 22:14:26 IPv6-Präfix wurde erfolgreich aktualisiert. Neues Präfix: 2a00:6020:...
21.10.22 21:55:41 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2a00:6020:...
21.10.22 21:55:41 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2a00:6020:...
21.10.22 19:48:26 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 ()
21.10.22 19:44:20 Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)
21.10.22 19:43:06 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 ()
21.10.22 19:38:43 Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)
21.10.22 19:29:03 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 ()
21.10.22 19:25:19 Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)
21.10.22 19:25:03 Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 ()
21.10.22 19:24:48 IPv6-Präfix konnte nicht bezogen werden, Fehlergrund: 4000 (lease timed out)
21.10.22 19:24:48 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig. Habs aber erst heute morgen gesehen. Wahrscheinlich hab ich es nicht bemerkt, weil die IPv4 Verbindung bestehen blieb. Ich hab zu der Zeit Streaming Dienste benutzt.
Was noch viel interessanter ist, ich hab nun ein komplett anderes IPv6 Prefix als vorher. Meine IPv6 Adresse und das Prefix passten immer noch zu dem alten Schema, dass hier im Forum auch mal erläutert wurde, wo man anhand der IPv6 Adresse das Prefix "berechnen" konnte. In vielen Anschlussbereichen ist das ja inzwischen anders, nun auch bei mir. Das heißt für mich, dass es hier definitiv Änderungen in der Infrastruktur gegeben hat, vielleicht in der Software der DHCP Server.
Wie dem auch sei, der erste Ernstfall für meine DynDNS Infrastruktur. Ich betreibe einen eigenen dyndns Server auf einem VPS, der dann die Einträge weiterverteilt an andere dyndns Dienste, um Redundanz zu haben. Diese anderen Einträge werden dann wieder von Überwachungsscripten getrackt, ob auch alle Daten angekommen sind. War bei einem nicht der Fall, somit hatte dieses Event am Ende soagr noch was gutes.
IPv6 Prefixes ändern sich bei mir nämlich nur äußerst selten. Seit Schaltung des Anschlusses Ende 2017 hatte ich zunächst den DG ONT mit einer 7490 im Einsatz, da gabs dauerhaft das gleiche Prefix. Geändert hat es sich im Februar 2021, als ich die 5530 in Betrieb genommen habe. Nun wieder, und das erste Mal ohne Endgerätewechsel.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum