ich finde nur "Nokia" als OUI in der DUID des DHCP-Servers "merkwürdig".
Korrigiere: Gar nicht merkwürdig: Nokia -> ehemals N3K -> Cygna Labs ist ein Hersteller u.a. von Enterprise DDI-Lösungen (Aktuell "VitalQIP"), wäre also nicht ungewöhnlich für einen DHCP-Server.
Der Wechsel auf Nokia könnte durchaus sein, Nokia hatte bekannt gegeben das Netz zu modernisieren.
Nokia will provide a full suite of fixed access and IP network products including its next-generation PON fiber solution, capable of supporting GPON, XGS-PON and 25G PON on the same fiber, along with its Broadband Network Gateways (BNG). Nokia is swapping out two competitors’ installed basis of IP Core, BNG and Edge Routers including related services.
"Modernisierung". Vielleicht sollten sie erstmal einen funktionierenden DHCP Server schreiben.... Oder vielleicht einfach einen funktionierenden Open Source DHCP Server nutzen.
ich finde nur "Nokia" als OUI in der DUID des DHCP-Servers "merkwürdig".
Guckst Du hier:
Nokia-Harware duerfte jetzt durch das ganze DG Netz zu finden sein, vermutlich eher keine ausreichende Information um das antwortende Netz-Element zu lokalisieren.
Also wenn ich das richtig verstehe ist im OLT ein DHCP relay agent. Dieser fügt Option 82 hinzu, damit der DHCP Server dann den Subscriber identifizieren kann. Ich nehme an sowohl OLT als auch DHCP Server / Router / Gateway sind Nokia bei dem neuen Anschluss.
Was hat DG vorher verwendet? Huawei?
Das ergibt in Anbetracht der Laufzeit und Endgerätefreiheit deutlich mehr Sinn.
Was hat DG vorher verwendet? Huawei?
Nokia.
Sowohl mein alter ONT aus dem Jahr 2020, als auch der mich bedienende OLT ist von Nokia/Alcatel Lucent. Aus meiner 5530er Fritze:
Details zum Netzbetreiber
Hersteller/Modell: Nokia
Versionsnummer: R6.2.04
Und aus dem Deep Dive: RE: Deep Dive SFP-Modul GPON ONU Stick von FS.com
Die ipv6 link local von der die Pakete kommen ist fe80::22, also nicht nach EUI-64. Und die mac Addresse passt auch nicht zur server duid. Die ist 20:00:12:....
fe80::22 scheint (an Anschlüssen neuerer Art) die universell vom BNG eingesetzte linklokale (software-generierte) Adresse auf dem Interface zu einem Kundenanschluss zu sein - von dieser Adresse werden auch die RA gesendet, und sie ist somit das dynamisch gelernte Standardgateway.
Ich habe gerade mal in einen Paketmitschnitt eines anderen Falls hier aus dem Forum geschaut: Dort beginnt die zur Adresse fe80::22 gehörende MAC-Adresse mit 20:00:10. Ein OUI-Lookup findet sowohl für 20:00:12 als auch für 20:00:10 keinen Treffer - ich gehe davon aus, dass auch diese MAC-Adressen software-generiert sind.
Die Server-DUID in einem DHCPv6-Paket muss auch nichts mit der MAC-Adresse im Ethernet-Header zu tun haben. Im erwähnten Paketmitschnitt lautet die MAC-Adresse des DUID-Typs 3: 80:b9:46:f0:0d:30 (OUI = Nokia).
Übrigens: In dem Paketmitschnitt, den ich gerade in meinem letzten Beitrag erwähnt habe, lautet der DHCPv4 Server Identifier ebenfalls 192.168.101.1.
Danke für die Infos. Das überschneidet sich alles mit dem was ich hier sehe.
Ich weiß nicht ob ich das positiv oder negative sehe? Ist es schlimmer das ein Anschluss merkwürdig konfiguriert ist -> keine Automation oder ist es schlimmer wenn alle neuen Anschlüsse so konfiguriert werden?
Es sollte besser niemand an DG Anschlüssen 192.168.101.0/24 verwenden. Ich habe das Subnet tatsächlich in an einer anderen Location. Aber site-to-site VPN mache ich nur per IPv6 ULA, wegen genau solcher Probleme.
Heute habe ich erneut das Prefix verloren.
Danke für die Infos. Das überschneidet sich alles mit dem was ich hier sehe.
Hier noch die Vergleichsquelle:
Thread "Kein Traffic über IPv6 möglich (Deutsche Glasfaser)" vom 01.11.2024.
Dort der Fall von sh0rty beginnend mit #115 am 23.01.2026 und sein Paket-Mitschnitt in #119.
Danke
Hier noch die Vergleichsquelle:
Thread "Kein Traffic über IPv6 möglich (Deutsche Glasfaser)" vom 01.11.2024.
Dort der Fall von sh0rty beginnend mit #115 am 23.01.2026 und sein Paket-Mitschnitt in #119.
Den einzigen Unterschied den ich erkenne ist das seine Leasedauer dauerhaft 600s zu sein scheint. Das ist bei mir immer nur initial so, danach immer 1h.
Aber das verlieren des DHCPv6 Lease nervt mich. Ich denke ich werde nochmal eine Anfrage bei DG stellen.
Aber das verlieren des DHCPv6 Lease nervt mich.
Ich denke, du meinst eher den Zeitpunkt des Lease-Verlustes (während üblicher Internet-Nutzungszeiten), nicht den Verlust als solchem mit Zuweisung geänderter Adressen?
Ich denke, du meinst eher den Zeitpunkt des Lease-Verlustes (während üblicher Internet-Nutzungszeiten), nicht den Verlust als solchem mit Zuweisung geänderter Adressen?
Beides
Die Änderung des Präfixes macht halt ohne Grund bestehende TCP Verbindungen kaputt. Außerdem ist für einen kurzen Zeitraum gar kein IPv6 möglich (zugegebener Weise nur so ca. 1 Sekunde).
Du hast allerdings keinen Anspruch auf quasi-statische IPv6-Adressen. Das ist seitens DG nur ein "nice to have" (in der Regel bei älteren Anschlüssen).
Kannst du mir bitte noch verraten, wie genau der Verlust der Lease abläuft?
Kannst du mir bitte noch verraten, wie genau der Verlust der Lease abläuft?
- Wird ein Renew (oder ggf. Rebind) explizit mit einem NAK abgelehnt?
- Oder läuft einfach der Leasetimer (1h) ab?
Anbei der Mitschnitt vom Verlust heute 17:33:30 UTC.
Du hast allerdings keinen Anspruch auf quasi-statische IPv6-Adressen. Das ist seitens DG nur ein "nice to have" (in der Regel bei älteren Anschlüssen).
Auch wenn ich vielleicht keinen Anspruch darauf habe, kann es mich trotzdem nerven😅.
Außerdem finde ich so eine "virtuelle" Produkseparation maximal bescheuert. Ein quasi statisches Präfix verursacht ja keinerlei weitere Kosten beim ISP. Wenn es tatsächlich Absicht ist, was ich teilweise anzweifle.
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
