Delegated IPv6 Präfix wird sehr zeitverzögert aktualisiert

[franco]

Hi Cuberturtle,

Nach ein paar Tagen IPv6 Sprint scheint vor allem 05c6f2e vielversprechend.


Grüsse
Franco

[Cyberturtle]

Ah super, danke für die Info. Verstehe ich die Sourcen richtig, dass nun bei neuem Prefix ein force renew bei IPv6 für die Interfaces ausgelöst wird?

Beste Grüße
Cyberturtle

PS: Find's super, dass ihr an der IPv6-Sache trotz des teilweise fragwürdigen Tons auf Github noch dran seid. 

Edit: Achso und soll ich meine radvd-Anpassung mit den verkürzten Lease-Zeiten wieder zurücksetzen für den Test?

[franco]

Viel hilft viel. Im Log ist mit dem Patch (übrigens am besten neu starten oder zumindest das Interface rekonfigurieren) ersichtlich ob dann doch erneuert wurde trotz gleicher IP (force: yes) und das lässt dann auch radvd neu starten und der alte Prefix sollte weg sein von den Clients.


Grüsse
Franco

[Cyberturtle]

Hey Franco,

der Patch sieht in der Tat vielversprechend aus. Ich hab's zwischendurch mal gestetet. Das System zeigte keine Instabilitäten und ich habe am WAN dann mal das Kabel zum Modem getrennt und wieder eingesteckt und der Präfix hat die Clients erreicht!

Ich habe mir mal erlaubt es mit pfSense+ zu vergleichen. Mit pfSense CE lief IPv6 nicht zuverlässig, mit der Plus-Version scheint IPv6 dort ebenso sauber wie mit dem Patch zu laufen. Allerdings habe ich an meinen Clients (hab's auf die Schnelle nur mit Windows gestetet) ein anderes Verhalten zwischen beiden Systemen bemerkt.
Bei OPNsense ist der alte Präfix weg und der neue da. Bei pfSense+ sind die alten Präfixe als verworfen gekennzeichnet unter Windows und der neue wird genutzt.
Für mich ist beides in Ordnung, ich wollte es nur vollumfassend berichten. 

Ich denke, wir sind auf dem richtigen Weg bei OPNsense. Mir ist von der thermischen Seite allerdings was aufgefallen. Ich habe keine Ahnung, ob's am Patch liegt oder an den Sensor-Treibern, allerdings sind die Temperaturen mit OPNsense wesentlich höher. Ebenso sind die Lastspitzen andere. Interessanterweise werden mir bei OPNsense per SSH auch andere Temperaturen angezeigt als im Widget (je nachdem, wie ich auslese). Mittels "sysctl -a dev.cpu | grep "temp"" sind die Temperaturen ca. 10 Grad kühler als mittels "sysctl -a | grep "dev.cpu"".

[Cyberturtle]

Hey Franco,

ich habe heute den Patch nochmal probiert und dabei die Option "Prevent release" deaktiviert gehabt. Funktioniert. Übrigens zeigt mir Windows heute an, dass die alten Prefixe ungültig sind. Keine Ahnung, ob das gestern einfach nur ein Schluckauf war.

Was mir allerdings aufgefallen ist. Die Internetverbindung muss mindestens 30-60s weg sein, bis PPPoE als down erkannt wird. Zwischendurch wurde es so nämlich sonst nur als Packetloss erkannt und es haben sich die IP-Adressen am WAN nebst Präfixen nicht verändert. (Das hatte ich aber auch schonmal vor dem Patch beobachtet, dass es lange dauern muss). Ich habe keine Ahnung, wie lange so eine nächtliche Zwangstrennung bei ASSIA dauert oder bei einigen Fällen, wo es den daily reconnect gibt.

Das Gateway-Monitoring habe ich übrigens deaktiviert. Damit werde ich nachher vielleicht auch nochmal testen.

Muss ich eigentlich vor dem nächsten regulären Update ein revert vorher durchführen?

Viele Grüße
Cyberturtle

[Cyberturtle]

Mir ist in den Logs noch etwas aufgefallen. Ich weiß nicht, ob die beiden IP-Adressen, die als new und old angegeben werden für den internen Vergleich herangezogen werden, weil dann wäre bei mir noch etwas unklar.
Bei der new-Adresse wird bei mir korrekterweise die WAN-Adresse angezeigt (igc1, pppoe0), bei der old-Adresse allerdings die Adresse des (igc2, opt1). Aus meiner Sicht wird quasi die falsche alte Adresse angezeigt. Die Adresse lag am GuestLAN tatsächlich an, aber nicht am WAN.

Ich hab davon mal einen Screenshot in den Anhang gepackt.

Edit: Ich kann das übrigens nicht reproduzieren. Manchmal (überwiegend) werden auch die richtigen Interface-IDs am Ende angezeigt, also quasi die 10f8 statt der 10fa. Ich kann mir den Wechsel der Interface-IDs daher nicht wirklich logisch herleiten. Ich habe auch einen Log-Eintrag gefunden, wo bei new die :10fa am Ende mit der old :10f8 angegeben wurde.

[franco]

Hi Cyberturtle,

Danke für die Infos.

> Ich habe mir mal erlaubt es mit pfSense+ zu vergleichen. Mit pfSense CE lief IPv6 nicht zuverlässig, mit der Plus-Version scheint IPv6 dort ebenso sauber wie mit dem Patch zu laufen.

Das scheint mit etwas suspekt, wenn die CE Version ja die Grundlage der Plus sein soll und diese dann (besser) als unsere Software funktioniert? Ich werde das mal beobachten...

Bei den Temperaturen bin ich etwas ratlos weil es auf die Hardware ankommt. Wir haben bei unseren Boxen auch ein Offset von 10 Grad eingestellt da die Temperaturen auch zu hoch angezeigt werden standardmässig. Ob das jetzt ein Bug oder Feature von FreeBSD 13 ist weiss ich nicht. Also das hier für amdtemp(4):

dev.amdtemp.0.sensor_offset -> -10

> Die Internetverbindung muss mindestens 30-60s weg sein, bis PPPoE als down erkannt wird.

Das sollte dann schneller funktionieren mit Gateway Monitor eingeschaltet. In pfSense ist der ja standardmässig an und dann reagiert das auch schneller aus aus der mdp5-Software in einen Timeout zu rennen mit PPPoE.

> Muss ich eigentlich vor dem nächsten regulären Update ein revert vorher durchführen?

Revert beim Update macht das Update selbst. Das ist dann nur unpraktisch wenn ein Patch noch nicht im Release ist. Den muss man das noch mal neu Aufspielen. Aber das RENEW/REBIND sollte in 23.1.8 kommen. Sehe da keine Probleme bislang.

> Bei der new-Adresse wird bei mir korrekterweise die WAN-Adresse angezeigt (igc1, pppoe0), bei der old-Adresse allerdings die Adresse des (igc2, opt1).

Ich weiss warum. das OPT1 ist doch bestimmt als Track Interface konfiguriert. Das lässt sich beheben.


Grüsse
Franco

[Cyberturtle]

Hi Franco,

sehr gerne. Ich versuche so viel Input/Infos wie möglich zu liefern. Das scheint mir hilfreicher als einfach nur zu "nörgeln".  Da ich ja selbst ITler bin, ist mir auch klar, dass es keine fehlerfreie Software gibt. Gibt da ja so die schöne Kette Fehlerwirkung -> Fehlerzustand -> Fehlhandlung. Manche Bugs sind in einigen Fällen halt nur nerviger.

Ich hab's mit der Plus-Version übrigens keine vier Stunden ausgehalten.  MTU bzw. MSS-Clamping funktioniert nicht sauber, den Traffic Shaper konnte ich echt vergessen und dann haben mir noch die IPv6-DynHost-Aliase gefehlt. Ich würde daher nicht sagen, es läuft "besser". Eben anders. Mir kommt OPNsense irgendwie reaktionsfreudiger vor und ich glaube, es ist für den Telekom-Anschluss irgendwie kompatibler. Ich konnte IPv6 mit der CE wirklich so gar nicht richtig in Gang kriegen. Bei gleichen Einstellungen habe ich dann ein Upgrade auf Plus durchgeführt und es ging. Allerdings scheinen dafür andere gar kein IPv6 mehr zu haben, wenn ich das im Forum dort richtig gelesen habe. Tja, kochen halt auch nur mit Wasser. 

Gibt es einen Sensor-Offset auch für Intel? Bei mir kommt nämlich ein J4125 zum Einsatz. Ich hab übrigens gestern mal Hardware CRC aktiviert (also das Häkchen entfernt). Damit ist die CPU-Last etwas runtergegangen.

Das Gateway Monitoring hatte ich für IPv4 schon aktiv, nur nicht für IPv6. Da werde ich dann auch mal den guten alten Google Public DNS für verwenden.

Ja, OPT1 (igc2) und LAN (igc0) sind bei mir beides Track Interfaces. Einmal Guest/Work und Privat.

Kommt der dhcp6c-Patch, den du hier ursprünglich verlinkt hattest, auch mit in die 23.1.8?

Beste Grüße
Cyberturtle

[Tuxtom007]

Ich kann von meiner Installation nicht sagen, das die Prefix-Delegation lange dauert.

Hatte gerade einen Prefix-Wechsel, weil Vodafone am Kabelnetz rumfummelt ( Wartungsarbeitung ) und dadurch es zu mehreren Ausfällen kam.
Nachdem die Leitung wieder stabil lief ( FritzBox 6951 im BridgeModus vor der OPNSense ) bekommen die OPNsense ihren neuen Prefix und die VLAN die Delegation direkt danach.
Das dauert keine Minute.

[franco]

> Gibt es einen Sensor-Offset auch für Intel? Bei mir kommt nämlich ein J4125 zum Einsatz. Ich hab übrigens gestern mal Hardware CRC aktiviert (also das Häkchen entfernt). Damit ist die CPU-Last etwas runtergegangen.

Habe geschaut im Quellcode aber scheint es nicht zu geben. Sorry.

> Das Gateway Monitoring hatte ich für IPv4 schon aktiv, nur nicht für IPv6. Da werde ich dann auch mal den guten alten Google Public DNS für verwenden.

Sollte dann aber auch für IPv6 schon reagieren da es ja über die gleiche Einwahl geschieht.

> Ja, OPT1 (igc2) und LAN (igc0) sind bei mir beides Track Interfaces. Einmal Guest/Work und Privat.

https://github.com/opnsense/core/commit/bde52467d
# opnsense-patch bde52467d

> Kommt der dhcp6c-Patch, den du hier ursprünglich verlinkt hattest, auch mit in die 23.1.8?

Denke ja, keine Beschwerden bislang.


Grüsse
Franco

[Cyberturtle]

Hey Franco,

heute hatte ich leider einen reellen Use Case zum Test. Im DSLAM gab's nen Schluckauf und die Leitungen am Bündel wurden alle neugestartet. Die Interfaces hatten nach ca. 2 Minuten, als die Leitung wieder synchron war, auch die neuen Prefixes gezogen.
Das scheint prinzipiell zu funktionieren.
Leider haben nur meine WiFi Clients noch immer den alten Prefix bevorzugt drin. Ich habe keine Ahnung, ob das nen "Bug" jetzt noch im UniFi-AP ist oder einfach ein Verhalten der iOS-Geräte, die trotz des neuen Präfixes noch den alten bevorzugen. Ich vermute mal, das liegt an der AdvPreferredLifetime. Ich hatte nach dem Patch das Router Advertisment auf Default gesetzt, allerdings gehen dann die Zeiten ziemlich nach oben.
Vermutlich haben die WiFi Clients einfach nicht das deprecated empfangen, damit kann ich allerdings leben, da ich die Zeiten wieder entsprechend anpassen werde.
Aus meiner Sicht, wenngleich ich sicherlich nicht für alle reden kann, spricht nichts gegen den Patch im Release.

Beste Grüße
Cyberturtle

Edit: Vielleicht liegt es nicht nur an den Zeiten. Ich habe gerade mal testweise auf "Save" in den Router Advertisement geklickt und schwupps hatten alle WiFi-Geräte den neuen Präfix. Wird denn mit dem Patch auch das RA neugestartet? Ich sehe in den Logs nach dem Reset der Leitung jedenfalls unbound, vlan etc. mit einem (re)configure. Den radvd konnte ich jedenfalls nicht in den Logs finden.

Edit2: Ich vermute dennoch irgendwie die UniFi-APs als Ursache, da die kabelgebundenen Clients keine Probleme hatten.

[franco]

Ok, so weit so gut. Bzgl. radvd und neuem Prefix: der Reload sollte eigentlich auch durch den Prefix Wechsel durchgehen. Kannst du im Log prüfen, z.B.:

# opnsense-log | grep dhcp6c_script
dhcp6c_script: REQUEST on igb1 executing
dhcp6c_script: REQUEST on igb1 renewal (REASON)
dhcp6c_script: RENEW on igb1 executing
dhcp6c_script: RENEW on igb1 executing
dhcp6c_script: RENEW on igb1 executing
dhcp6c_script: RENEW on igb1 renewal (PDINFO)

Es kann aber auch sein dass radvd nicht die richtige Adresse bekommen hat und dann der Reload fehlschlug (nur SIGHUP und das macht kein deprecate). Da können wir dann auf Basis 23.1.8 noch mal debugggen.


Grüsse
Franco

[Cyberturtle]

Hey Franco,

vielen Dank für die Rückmeldung. Nach dem Reboot war bei mir das Log leider leer bis auf den Eintrag nach dem Reboot. Ich bin schon auf die 23.1.8 gespannt und nehme mir dann gerne Zeit für weiteres Debugging, falls erforderlich.

Beste Grüße

[franco]

Anmerkung zum Thema:

Heute haben wir die Fritzbox noch mal genauer angeschaut.

Neustart der FB oder LAN-Kabel raus geht alles prima.

"Neu verbinden" im Online Monitor der VB: läuft irgendwie alles weiter.

DSL/Telefon abklemmen: oh oh...

Die FB verliert doch tatsächlich das Wissen über die vergebenen Leases nach dem harten Neuverbinden anders als beim Knopf "Neu verbinden". Das bringt 2 Probleme mit sich:

1. Der Client mit dem aktiven Lease weiss nicht, dass das Lease nicht mehr existiert. Der Client meldet sich erst wenn er ein RENEW anfordert. Das dauert hier im Netzwerk bis zu 30 Minuten!

2. passiert dann beim RENEW folgendes: Der Server schickt eine leere Antwort mit dem Status Code "NoBinding"[1]. dhcp6c kann damit nichts anfangen und akzeptiert dies als valide Antwort (ohne Prefix oder Adresse). Dann probiert es ein REBIND. Bei diesem besteht genau das gleiche Problem. Und dann wartet es auf irgendeine Aktion auf dem Link oder Zwangstrennung der dann die Situation wieder gerade biegt. Das kann dann aber schon mal einen halben oder ganzen Tag dauern je nach dem wann der DSL Ausfall war.

Einen Patch für 2.) wäre https://github.com/opnsense/dhcp6c/commit/555bdcdeff3e0f4

Im Debug Mode für DHCPv6 findet sich sowas hier im System Log:

# opnsense-log | grep status.code..no.binding
dhcp6c 62966 status code: no binding
[...]

Wer den Patch ausprobieren will:

# pkg add -f https://pkg.opnsense.org/FreeBSD:13:amd64/snapshots/misc/dhcp6c-20230523_1.pkg

(am besten neu starten)

# opnsense-log | grep resetting.lease
dhcp6c 18251 - resetting lease on igb1

In dem Fall hat es dann zugeschlagen..

Zu 1.) sieht es mir nach einem Fehlverhalten der FB aus oder dhcp6c hat noch andere Probleme. Ich kenne mich mit den relevanten RFCs nicht gut genug aus.


Grüsse
Franco

[1] https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-5

[Cyberturtle]

Hey Franco,
bezüglich RFC könnten wir uns ja mal austauschen. Zumindest habe ich die RAs versucht daran anzulehnen und anzupassen als ich mich mit dem Thema hier angefangen habe zu beschäftigen.
Ich habe leider keine Fritzbox vorgeschaltet. Ich verwende nen Speedport Smart 4 als simples Modem. Da sollte ja dann alles schick sein?
Was macht die Fritzbox denn anders, wenn sie selbst als Router fungiert nachdem das DSL wieder da ist? Evtl. könnte man da mit Wireshark mal schauen, wie da die Clients mit dem neuen Präfix versorgt werden. Ist gerade mal so in die Tastatur gedacht.
Beste Grüße
Cyberturtle