DHCP Lease-Time bei CGNAT

    Hier sind ja einige bei Providern unterwegs, die mit CGNAT arbeiten. Ich nehme gerade etwas naiv an, dass diese immer mit DHCP statt PPPoE arbeiten.

    Wie sieht es da typischerweise mit der Lease-Time aus? Minuten, Stunden, Tage? Wie sind da eure Erfahrungen? Habt ihr da kurzfristige Unterbrechungen beim Renewal erfahren?

    Bei der DG sind es 60 Minuten, also alle 30 Minuten wird das Lease erneuert. Daraus entsteht ja immer die Diskussion um die 60 Minuten Wartezeit beim Routertausch, da nur ein Lease pro Anschluss verteilt wird.

    Der Renew sollte ja eigentlich nur die bestehende Adresse erneuern. Kommt es da zu spürbaren Unterbrechungen oder Verzögerungen auf bestehenden (TCP-) Verbindungen?

    Der Hintergrund meiner Frage ist, dass ich das im Zusammenspiel OpenWRT und Zyxel Nr7302 (IP-Passthrough mittels DHCP) durchaus wahrnehme.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Evtl. ist die Frage, wie der Zyxel-IP Passthrough Mode im Detail arbeitet. Denkbar wäre ja, dass der Zyxel DHCP-Renews/Rebinds oder deren Replies von der Gegenstelle nicht weiterleitet (warum auch immer), so dass der OpenWRT regelmäßig in Lease-Timeouts liefe (bei DG alle 3600s sowohl für IPv4, als auch für IPv6). Es käme dann jeweils zu Netzunterbrechungen, solange, bis in einem neuen DHCPv4/DHCPv6-Exchange (der offenbar mit IP Passthrough funktioniert) wieder IP- bzw IPv6-Adressen zur Verfügung stehen (hoffentlich dieselben wie zuvor).

    Nur so ein Gedanke, der die Beobachtungen erklären könnte.

    Zitat von ::1

    Evtl. ist die Frage, wie der Zyxel-IP Passthrough Mode im Detail arbeitet. Denkbar wäre ja, dass der Zyxel DHCP-Renews/Rebinds oder deren Replies von der Gegenstelle nicht weiterleitet (warum auch immer), so dass der OpenWRT regelmäßig in Lease-Timeouts liefe (bei DG alle 3600s sowohl für IPv4, als auch für IPv6). Es käme dann jeweils zu Netzunterbrechungen, solange, bis in einem neuen DHCPv4/DHCPv6-Exchange (der offenbar mit IP Passthrough funktioniert) wieder IP- bzw IPv6-Adressen zur Verfügung stehen (hoffentlich dieselben wie zuvor).

    Nur so ein Gedanke, der die Beobachtungen erklären könnte.

    Ich habe jetzt mal einen genaueren Blick darauf geworfen und das scheint deine Vermutung zu stützen. Ich denke, dass der DHCP-Renewal nicht implementiert ist. Ich habe mal den Lease auf 120 Sekunden gesenkt.

    Das Interface in OpenWRT geht down und ich habe in der Schleife einen Sleep von 1 Sekunde zwischen dem erneuten Aufruf des Pings gesetzt. Das Interface ist nach 3 Sekunden wieder da. In Summe mit den verlorenen Paketen sind es gut 12 Sekunden. Ich teste mal eine TCP-Verbindung währenddessen.

    Und gleich noch einen tcpdump währenddessen.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    So, Verdacht bestätigt.

    Das erste Paket scheint mir der Renewal-Request zu sein. Das wird allerdings mit einem NACK/Lease not found gekontert und danach geht das Interface down und ein neuer Request wird gestartet.

    So weit, so schade.

    Zitat von mbo77

    Hier sind ja einige bei Providern unterwegs, die mit CGNAT arbeiten. Ich nehme gerade etwas naiv an, dass diese immer mit DHCP statt PPPoE arbeiten.

    Wie sieht es da typischerweise mit der Lease-Time aus? Minuten, Stunden, Tage? Wie sind da eure Erfahrungen? Habt ihr da kurzfristige Unterbrechungen beim Renewal erfahren?

    Mit der Adressvergabe hat das nichts zu tun. Bei uns haben noch einige (wenige) Kunden eine PPPoE Einwahl und haben trotzdem danach CGNAT. Ich meine Purtel/DGN machen das auch so.


    Leasetime bei EON Highspeed sind afaik 3600s bzw 1800s bei IPv6.

    Frustrierenderweise sieht es auf dem administrativen Netz besser aus:

    Hier wird der Renewal offenbar sauber bestätigt. Die Frage ist, weshalb das im Passthrough nicht funktioniert.

    Das würde mich ja nicht sonderlich stören, wenn das ganze Setup ohnehin nicht merkwürdig wäre.

    Solange noch kein Login zum APN erfolgt ist (nach Reboot), bekommt das Interface erstmal einen Lease vom definierten Subnetz auf der Bridge. Die DHCP-Option muss aktiviert sein, sonst bedient der auch nicht den Passthrough.

    Stelle ich den Lease also zu hoch (z.B. stündlich), dann habe ich zunächst erstmal nur eine IP vom Zyxel oder muss das Interface manuell neu starten.

    Stelle ich den Lease auf 2 Minuten, ist das natürlich auch nach Reboot ok, kommt dann aber zum beschriebenen Schluckauf, da der Renewal fehlschlägt.

    Die Anbindung ist eigentlich stabil, sodass ich auch mit einem Lease über einen Tag gut arbeiten könnte. Kommt es aber doch mal zum Relogin zum APN oder der triggert eine neue IP, dann hängt die Verbindung bis zu einem halben Tag.

    Ich werde das Verhalten mal im Zyxel-Forum anfragen. Aber wie ich in meinem Erfahrungsbericht schon schrieb: Software und Support sind eher schlecht. Liegt vielleicht auch daran, dass Zyxel die HW eigentlich nur an Provider herausgibt.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von kingpin42

    Mit der Adressvergabe hat das nichts zu tun. Bei uns haben noch einige (wenige) Kunden eine PPPoE Einwahl und haben trotzdem danach CGNAT. Ich meine Purtel/DGN machen das auch so.


    Leasetime bei EON Highspeed sind afaik 3600s bzw 1800s bei IPv6.

    Hehe, ich hatte diese Spitzfindigkeit fast schon erwartet und habe überlegt, wie ich es präzise formuliere. ;)

    Zitat von mbo77

    Hier wird der Renewal offenbar sauber bestätigt. Die Frage ist, weshalb das im Passthrough nicht funktioniert.

    Du beschreibst deinen Aufbau nur sehr dürftig - man muss viel raten!

    Was ich glaube herausgelesen zu haben:

    • Es besteht ein VLAN-Trunk zwischen deinem OpenWRT und dem Zyxel:
      VLAN 57: 192.168.1.0/24 mit der Zyxel-IP 192.168.1.1 - wird genutzt für IP-Passthrough
      VLAN 2: 192.168.2.0/24 mit der Zyxel-IP 192.168.2.1 und der OpenWRT-IP 192.168.2.140 - "administratives Netz" (zum Managen des Zyxel)
    • Solange noch kein APN-Login erfolgt ist, bekommt der OpenWRT im VLAN 57 eine IP-Adresse aus 192.168.1.0/24. Danach soll dem OpenWRT aber natürlich eine WAN-Port-IP vom ISP via DHCP über IP-Passthrough zugewiesen werden. Das wäre dann die IP-Adresse 10.132.0.189 aus dem Netz 10.132.0.188/30, mit der ISP-DHCP-Server-ID 10.132.0.190 und der Broadcast-Adresse 10.132.0.191 (private Adresse, weil hinter CGNAT).

    Was mich irritiert (oder auch nicht): Der Zyxel scheint sich als eine Art DHCP-Proxy (nicht zu verwechseln mit DHCP-Relay!) in die Bridge-Funktion des IP-Passthrough 'reinzuhängen'. Er scheint das aber irgendwie nicht richtig zu machen: Solange kein APN-Login besteht, bedient er den OpenWRT in VLAN 57 aus einem lokalen IP-Pool (192.168.1.0/24). Leider gibt es bei DHCPv4 m.W. keine Funktion, mit der man eine Lease aktiv wieder zurückziehen kann, was ja notwendig wäre, sobald ein APN-Login erfolgt ist. Daher muss die Leasedauer dieser lokalen Lease (aus 192.168.1.0/24) sehr kurz eingestellt sein, damit der OpenWRT seinerseits aktiv wird und eine neue Lease anfordert.

    Bei dieser zweiten Lease-Anforderung muss der Zyxel-DHCP-Server aber nun die Rolle eines Proxy für den DHCP-Server des ISP (10.132.0.190) einnehmen, d.h. er muss insbesondere auch die von diesem gelieferten Leasedauern (sowie RN/RB) weitergeben und nicht etwa seine lokal konfigurierten Werte (macht er aber nicht). Das NAK als Antwort auf ein Renew scheint daraus zu resultieren, dass er die Adresse 10.132.0.189 des OpenWRT in seinen lokalen DHCP-Pools nachschaut, dort existiert sie natürlich nicht. Das Renew für 192.168.2.140 funktioniert hingegen, weil diese Adresse aus einem lokalen DHCP-Pool des Zyxel stammt.

    Eine Proxy-Funktion scheint mir tatsächlich auch nötig, da IP-Passthrough eine Form einer Bridge darstellt, bei der MAC-Adressen ersetzt werden. Da die MAC-Adresse des OpenWRT (82:62:a4:e2:85:c0) auch als Client-Ethernet-Address im DHCP-Paket steckt, muss diese dort (im Sinne einer ALG-Funktion) gegen die MAC-Adresse des Zyxel ausgetauscht werden, die der DHCP-Server des Providers (10.132.0.190) zu sehen bekommt.

    Möglicherweise musst du im Zyxel bzgl. der erwünschten (tatsächlich aber nicht vorliegenden) DHCP-Proxy-Funktion noch irgendwo Einstellungen ändern.

    3 Mal editiert, zuletzt von ::1 (27. Juli 2025 um 13:57)

    Soweit richtig analysiert, danke für die Bestätigung meiner Vermutung.

    Somit ergeben sich zwei Zielkonflikte in der aktuell realisierten Konfiguration: Um von der Adresse der lokalen Bridge (192.168.1.0/24) weg zu kommen, braucht es einen kurzen Lease, meinetwegen 2-5 Minuten. Damit kann ich nach Reboot leben.

    Schwerwiegender ist die verkorkste DHCP-Proxy/Relay Funktion. Dafür möchte ich eigentlich einen möglichst langen Lease haben. Aber auch da gilt, dass ein langer Lease stören kann, wenn der APN eine neue Adresse vergibt. Dann müsste zumindest der Zyxel die Verbindung kurz unterbrechen, um einen Reconnect zu erzwingen.

    Ich habe das mal in der Zyxel Community als Frage platziert, erwarte da aber nicht allzu viel.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Was mich daran ohnehin am meisten nervt: Das Subnetz auf der ungetaggted Bridge brauche ich überhaupt nicht. Für die Administration nutze ich das VLAN 2. Initial kommt man immer für 30 Minuten über WLAN auf das System.

    Die DHCP-Funktion muss eigentlich erst dann aktiviert werden, wenn im WAN eine Verbindung besteht.

    Ich werde jetzt vermutlich auf einen langen Lease wechseln (mindesten 24h) und mittels watchcat das Interface im OpenWRT überwachen und neustarten, wenn was in die Hose geht.

    Zitat von mbo77

    Schwerwiegender ist die verkorkste DHCP-Proxy/Relay Funktion. Dafür möchte ich eigentlich einen möglichst langen Lease haben.

    Du musst genau die Leasedauer haben, die der DHCP-Server des ISP vorgibt - die muss der DHCP-Proxy korrekt weitergeben (was er nicht tut).