IPv6 DTAG DualStack bzw. prefix delegation funktioniert nicht mehr
-
Und der Vollständigkeit halber:
Gab es hier ggf. Änderungen im Bereich 2.4.5? Zumindest ist mir der Bereich "Advanced Configuration" bei DHCP6 im Bereich WAN vorher nicht aufgefallen.
-
Wird dir zwar nicht viel nützen, aber ich habe die gleiche Konfiguration, auch eine DTAG Anschluss mit einer pfSense 2.4.5 und es funktioniert.
-
@nonick tut es bei mir ja auch... Immer mal wieder. :-) Ich könnte mir vorstellen, dass ein reboot hilft. Kannst ja mal ein PPPoE Reset über den Interfaces Button machen und schauen, ob Du neue IPs auf dem WAN Interface bekommst und es dann weiterhin funktioniert....
-
Auch das funktioniert bis jetzt reibungslos. erst vor ein paar Tagen war die Zwangstrennung.
-
@nonick Merci. Und ja... hilft mir nicht. :-)
Ist bei Dir die externe IPv6 (WAN) auch so komplett unterschiedlich zu den LAN-IPv6 Präfixen wie bei mir? Ich vermute ja, weil die DTAG vermutlich komplett unabhängige /56er Netze per DHCP announced..
-
Ist genauso, deine Vermutung ist auch richtig.
-
Ich danke Dir. Dann muss ich mal das WAN interface tracen, wenn ich ne Zwangstrennung mache und mir mal ansehen, was da mittels DHCP auf dem WAN Interface passiert und welche Präfixe überhaupt delegiert werden (in der Hoffnung, dass ich das erkenne)...
Liebe Grüße
JP -
Ok. PPPoE neu aufgebaut. Neue IPv6. Aber die IPs auf den LAN interfaces blieben. Spricht für meine Theorie.
Indizes von 1-3 auf 0-2 geändert. PPPoE neu. Die drei interfaces kriegen neue IPs. IPv6 geht. Sehr merkwürdig.
-
Spooky. In der Nacht gabs nen PPPoE Reset. Schwups war IPv6 wieder nicht verfügbar.
Dieses Mal habe ich nur die Track-ID von 0 auf 5 geändert und eine Minute gewartet. Siehe da: Es geht wieder ohne PPPoE Reset. Spricht dafür, dass hier irgendetwas bei der internen Prefixweitergabe aufs LAN Interface bei einem ungeplanten PPPoE Reset nicht klappt.
Auch Spooky: Ich habe die Track-ID von 0 auf 5 geändert, aber die IPv6 auf dem LAN Interface ist jetzt
2003:c8:9f39:4400 usw
statt
2003:c8:9f39:4405
denn auf den anderen Interfaces ist die Track-ID genau dort widergespiegelt.
Ich schau mal, was ich in den Logs finde....
-
Hast du mal probiert on in den WAN-Einstellungen für IPv6 ein Setzen von "Do not allow PD/Address release" etwas bei dir "positiv" bewirkt?
-
@wkn Bisher noch nicht. Nach meinem Verständnis wird bei jedem PPPoE Aufbau auch ein neuer /56 Präfix von der Telekom vergeben und delegiert. Alles andere wäre eine große Überraschung. Warum sollte man bei einem gewollten Exit seitens der pfsense keinen release schicken wollen... Ich kann das gerne mal einschalten aber inwiefern glaubst Du, dass das hilft?
Der PPPoE Reconnect kam wegen eines LinkLoss. Da wurde vorher keine PPPoE Session sauber bearbeitet (laut Logs).
-
Wie zeigt sich denn der Abbruch bei dir im Log?
Ich sehe z.B. wenn die Telekom nachts ihr Wartungsfenster ausführt und die Verbindung von da aus getrennt wird, fünf Timeouts vom LCP Ping und dann löst die pfSense darauf ein Down event aus. Wenn die Leitung dann wieder Sync wird, erfolgt der normale PPP Session Aufbau.
-
Schau mal hier bitte:
https://forum.netgate.com/topic/153596/ipv6-connectivity-from-lan-is-lost-after-pppoe-reconnect
Da habe ich es noch einmal auf Englisch zusammengeschrieben und auch die Logs vom PPPoE Abbruch reingepackt.
