Deine Bilder sind schön aber nutzlos, du musst die Protokolle ICMPv6 bzw. DHCPv6 jeweils aufklicken - deren Inhalte sind relevant. Die reinen Hex-Ausgaben brauche ich nicht - ich bin kein Computer ...
Aber mach bitte mal einen neuen Trace, nachdem du die Voreinstellung der Prefix-Länge deaktiviert hast.
Bzw: Hast du nun ein /56 LAN-Präfix nach Neu-Verbindung zugewiesen bekommen? Dann kannst du dir all den Aufwand sparen.
Und "Bestimmte Länge für das LAN-Präfix anfordern" steht auf 62 Bit
Bitte deaktivieren oder auf 56 setzen.
Kann mir jemand beantworten, ob es hier an der Router-Konfiguration oder an der DG liegt?
Jein:
Fragen:
Es sieht soweit gut aus, die DG-Gegenstelle sendet RA (Pakete 133, 7330) und NA. Per DHCPv6 erhältst du zumindest eine IPv6-Adresse für den WAN-Port (Pakete 114, 7324), aber jeweils unterschiedliche, was verdächtig ist.
Leider kann ich nicht sehen, ob du auch einen /56-LAN-Präfix per DHCPv6-PD bekommst. Dazu müsste man in die DHCPv6-Solicits (Pakete 113, 7323) hereinschauen, ob deine FB IA_PD anfordert, bzw. in die DHCPv6-Replies (Pakete 114, 7324), ob dort IA_PD enthalten ist.
kein "klassisches" (Keine Ahnung, welcher RFC das grad ist) Prefix Delegation
IPv6 Prefix Delegation (PD) ist ursprünglich im RFC3633 beschrieben, welcher durch Aufnahme in den aktuellen RFC für DHCPv6 (RFC8415) nun aber obsolet ist.
sondern RFC7278. ::1 weiß da sicher mehr
Danke für die Blumen, jedoch bin ich im Bereich IPv6 für Mobile-Netze nicht so unterwegs.
Aber ich habe mal recherchiert (ein freundlicher Service von "RFC - für Sie gelesen"):
Wie der zitierte RFC7278 schon im ersten Absatz des Intros besagt, steht DHCPv6-PD erst ab 3GPP Release-10 zur Verfügung.
Kann DHCPv6-PD nicht genutzt werden (weil der mobile ISP es nicht unterstützt), dann beschreibt RFC7278 eine Methode, wie das mobile Endgerät den /64-Präfix, den es standardmäßig per SLAAC bezieht, an ein nachgelagertes LAN durchreichen kann, wenn es sich bei dem Gerät tatsächlich um einen LTE-Router handelt.
Kann hingegen DHCPv6-PD genutzt werden, so beschreibt RFC6653 in Section 3.3, wie das abläuft.
Ansonsten siehe noch RFC6459 als allgemeine Referenz zum Thema.
Durch einen Paketmitschnitt am LTE-Port des Routers könnte man sicherlich herausfinden, welche Methode zum Einsatz kommt (wenn man dort keine DHCPv6-Solicits/Requests mit IA_PD sieht, sondern nur RS/RA für SLAAC, dann ist es die Methode gemäß RFC7278).
Ich weiß es nicht ob diese eine Änderung bei DG zeigt oder ist das reine Zufall.
Naja, zeigt halt die IPv4- oder IPv6-Adresse an, mit der du bei https://icanhazip.com/ aufschlägst. Im Falle von IPv4 ist das die CGNAT-Adresse, der DG, die deinem Anschluss (und anderen) aktuell zugeordnet ist. Im Falle von IPv6 (würde es funktionieren), wäre es die IPv6-Adresse deines Endgerätes.
Die Anzeige eines "leeren Blattes" würde ich so deuten, dass du die Site entweder nicht erreicht hast oder der Service zu dem Zeitpunkt gerade down war.
Habt ihr evtl. weitere Vorschläge, um der Quelle der Instabilität näher zu kommen?
Um deine beiden LAN-Kabel (das "kurze" PC <-> Router, das "lange" Router <-> ONT) in Kombination zu testen, folgende Idee:
Lass ein paar Minuten laufen und schau, ob du ähnliche PING-Aussetzer wie oben hast. Falls nein, sind deine Kabel in Ordnung.
Anschließend wieder alles rückbauen - nicht vergessen, am Notebook die Windows-Firewall wieder einzuschalten.
Wo ist PPPoE denn Gefrickel und fehlerträchtig ?
Das sicherlich nicht, es passt nur nicht besonders gut mit IPv6 bzw. IPv6/DS-Lite (siehe meine Argumentation in #24).
Bei DualStack ergibt sich m.E. auch eine Unklarheit, ob man IPv4 und IPv6 gemeinsam in einer PPP-Session oder jeweils in einer eigenen PPP-Session fahren möchte. Aber zu diesem Punkt fehlen mir tatsächlich Erfahrungswerte.
In der Konstellation erhält der primäre Router die Adresse per DHCP.
Das lese ich dort nicht heraus.
Ist ein 5G-Router und sticht die Adresse durch.
Wenn ich dem Link folge und dort lese, verstehe ich das so, dass der Zyxel (sekundärer Router) das PPPoE eines nachgelagerten (primären) Routers mehr (Bridge-Modus) oder weniger (IP-Passthrough-Modus) transparent durchreicht. Der nachgelagerte (primäre) Router muss dann aber trotzdem PPPoE machen, was dem OP nichts nützt, weil es sein Problem nicht löst.
Der Zyxel NR7302 macht genau so ein IP pass-through.
genau wie was?
Ich vermute, als ISP fühlen sich historisch Viele besser damit, dass der Kunde Zugangsdaten eingeben muss.
Ja, Authentifizierung ist tatsächlich ein gewichtiges Argument, das für PPP bzw. PPPoE spricht.
Allerdings erinnere ich mich an die letzte "Innovation" seitens der Telekom bezüglich meines vormaligen VDSL-Anschlusses, in deren Folge keine Authentifizierung mehr erforderlich war. Es scheint also andere, auf der Infrastruktur beruhende Mechanismen zu geben, die hinreichend gut sicherstellen, dass der Internetzugang nur durch den berechtigten/zahlenden Anschlussinhaber genutzt werden kann.
Ich würde gerne mal eine Grundfrage zu diesem Thread stellen:
Ist es nicht ziemlich sinnfrei seitens eines ISP, DS-Lite ausgerechnet via PPPoE anzubieten?
Meine Überlegung dabei:
In der Folge ergibt DS-Lite für mich nur in Verbindung mit IPoE einen Sinn.
Daher die Preisfrage:
Ist die aus meiner Sicht unsinnige Kombination DS-Lite/PPPoE dadurch zu begründen, dass der ISP halt aus seiner Historie heraus nur eine PPPoE-Einwahlstruktur zur Verfügung hat und eine Umstellung auf IPoE sehr aufwendig wäre? Oder übersehe ich andere gewichtige Aspekte, die für DS-Lite/PPPoE sprechen?
Wir brauchen die öffentliche feste IP vom ISP. Daher war der Gedanke, zwischen SachsenGigbit Modem und der UDM Pro SE ein "Modem" zu schalten, welches die PPPoE Einwahl übernimmt und dann die feste IP 1:1 via WAN an die UDM Pro Se weitergibt. Die Stichworte hierfür sind „Bridge Mode“, „IP Passthrough“, „PPPoe Passthrough“, „Routed Subnet / Routed LAN“ oder Ähnliches.
Ich kann mir nicht wirklich vorstellen, wie so ein zwischengeschaltetes "Modem" arbeiten sollte: Es würde nun mal Richtung ISP PPPoE sprechen (müssen) und hätte damit die öffentliche IPv4-Adresse für sich zugewiesen - die kann es folglich nicht mehr nach "hinten" zu deinem Router weitergeben (und dabei noch das L2-Protokoll von PPP auf Ethernet wechseln).
"Passthrough" würde bedeuten, dass dein Router zusätzlich PPPoE machen und das zwischengeschaltete "Modem" dies nur durchreichen würde. Aber dann macht dein Router ja doch wieder PPPoE mit der von dir bemängelten schlechten Performance. Zudem müsste dir dein ISP eine zweite öffentliche IPv4-Adresse spendieren, hängt vom Vertrag ab.
Nachtrag:
Im Grunde müsste das zwischengeschaltete "Modem" IPoE/DHCPv4 (was dein Router am WAN-Port sprechen würde, um nicht PPPoE machen zu müssen) auf PPPoE/IPCP umsetzen und insbesondere die via IPCP erhaltene IPv4-Adresse (nebst weiteren Optionen) via DHCPv4 an deinen Router zurückreichen. Ich habe noch nie von so einem Wundervogel gehört.
Ich habe mit Wireshark mitgeschnitten und wenn ich den 11 Post richtig interpretiere, habe ich das gleiche Problem
Ja, sieht ganz danach aus: Absolute IPv6-Funkstille bei der DG-Gegenstelle:
Ein ziemlich klarer Beweis, dass die DG kein IPv6 liefert ...
Dein 2. Screenshot im letzten Post zeigt, dass sowohl die IPv4- als auch die IPv6-Verbindung um 14:24:50 wegbrechen und binnen etwa 1 Minute wieder neu aufgebaut werden. Zuvor sieht man gerade noch, wie um 14:23:08 die IPv6-Verbindung wiederhergestellt wurde.
Liste doch bitte mal für den heutigem Tag die Uhrzeiten mit den folgenden beiden Meldungen auf:
"Internetverbindung wurde getrennt"
"Internetverbindung IPv6 wurde getrennt, ..."
Treten diese beiden Meldungen stets zeitgleich auf?
Sieht so aus, als hättest du ein "Blinker-Internet": AN - AUS - AN - AUS ... und das im Minutentakt.
Anbei eine Fehlermeldung, die eben aufkam als ich posten wollte.
Ja, leidiges Problem - siehe hier.
Ich würde die Wireshark-Prozedur noch versuchen, wenn das zur Klärung beitragen könnte.
Das bezog sich auf die Telefonie - die funktioniert nach dem Box-Reset ja offenbar inzwischen einwandfrei. Insofern erübrigt sich das.
Der Fokus sollte aktuell wohl eher auf der FB-Ereignisanzeige | TAB Internetverbindung liegen. Sieht man hier öfter Unterbrechungen der IPv4- und/oder IPv6-Internetverbindungen? Und falls ja, wie lange dauern jeweils diese Unterbrechungen?
Es könnte helfen (aber Achtung: sehr technisch), einen Paketmitschnitt am WAN-Port deiner Fritzbox durchzuführen, während du von deinem Schnurlos-Telefon versuchst, dein Handy anzurufen.
Die Vorgehensweise wäre wie folgt:
An einem beliebigen Windows-PC in deinem LAN:
Um dort "den Wald vor lauter Bäumen" zu finden, solltet du in der oberen Zeile "Anzeigefilter anwenden" den folgenden Ansichtsfilter eingeben:
sip || rtp.
Das sollte reichen, um den Versuch des Telefonanrufs anzuzeigen.
Mach bitte einen Screenshot von dem Wireshark-Bild (schwärze dort die angerufene Handynummer) und poste es hier.
Der Paketmitschnitt sollte losgehen mit einem "SIP/SDP-Request: INVITE sip:[Handynummer]@dg.voip.dg-dw.de]" gerichtet an eine der Adressen 185.22.44.186 oder 185.22.45.165 bzw. 2a00:6020:100:603::186 oder 2a00:6020:200:603::165, je nachdem, ob via IPv4 oder IPv6 telefoniert wird. Interessant wäre, ob so ein SIP-Request überhaupt deine Fritzbox in Richtung DG verlässt, und falls ja, wie die Reaktion der Gegenstelle aussieht.
4. Screenshot: Ein bisschen viel "DHCPv4 nak" - kommt das öfter vor?
