DHCP Lease-Time bei CGNAT

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?

frank_m

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.

mbo77

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.

pufferueberlauf

Das sollte ohne spuerbare Unterbrechung ablaufen... zumindest wenn die Adresse gleich bleibt...

mbo77

Das ist ja auch, was mich irritiert. Daher wollte ich mal aus der Praxis abgleichen.

pufferueberlauf

Vielleicht Zeit fuer Paketmitschnitte?

mbo77

Heute nicht mehr, vielleicht morgen.

frank_m

Ja, die Erneuerung erfolgt komplett nahtlos. Ich hab schon mal Wireshark Traces davon hier im Forum gepostet.

HubeBube

Yep, ich stimme frank_m zu. Es ist zumindest im Netz von Deutsche Glasfaser (DG) im Regelfall von einer Leseerneuerung nichts mit einer FRITZ!Box 5530 zu spüren.

Sworzi

Wenn alles gut konfiguriert ist , merkst man in 99,99 % der Fälle überhaupt nichts.

::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.

mbo77

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.

Code

64 bytes from 8.8.8.8: seq=50 ttl=112 time=17.671 ms
ping: sendto: Network unreachable		<= Interface geht verloren, ping scheitert
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable		<= Noch down nach sleep 1
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable		<= Noch down nach sleep 1
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable		<= Noch down nach sleep 1
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=112 time=20.373 ms		<= Interface wieder da
64 bytes from 8.8.8.8: seq=1 ttl=112 time=17.535 ms
64 bytes from 8.8.8.8: seq=10 ttl=112 time=16.651 ms	<= 9 Pakete (=9 Sekunden) gehen verloren

Alles anzeigen

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.

mbo77

So, Verdacht bestätigt.

Code

tcpdump: listening on br-lan.57, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:01:58.498998 82:62:a4:e2:85:c0 > 78:c5:7d:49:d2:98, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 41947, offset 0, flags [DF], proto UDP (17), length 328)
    10.132.0.189.68 > 10.132.0.190.67: [bad udp cksum 0x17c8 -> 0x55f5!] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0xa2551d5d, Flags [none] (0x0000)
          Client-IP 10.132.0.189
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            MSZ (57), length 2: 576
            Parameter-Request (55), length 8:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
            Hostname (12), length 4: "bpi4"
            Vendor-Class (60), length 12: "udhcp 1.36.1"
09:01:58.501860 78:c5:7d:49:d2:98 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 64, id 47510, offset 0, flags [none], proto UDP (17), length 328)
    192.168.1.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xa2551d5d, Flags [Broadcast] (0x8000)
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: NACK
            Server-ID (54), length 4: 10.132.0.190
            MSG (56), length 15: "lease not found"
09:02:01.720781 82:62:a4:e2:85:c0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0x45f45508, Flags [none] (0x0000)
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            MSZ (57), length 2: 576
            Parameter-Request (55), length 8:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
            Hostname (12), length 4: "bpi4"
            Vendor-Class (60), length 12: "udhcp 1.36.1"
09:02:01.731156 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 344: (tos 0xc0, ttl 64, id 4398, offset 0, flags [none], proto UDP (17), length 330)
    192.168.1.1.67 > 10.132.0.189.68: [udp sum ok] BOOTP/DHCP, Reply, length 302, xid 0x45f45508, Flags [none] (0x0000)
          Your-IP 10.132.0.189
          Server-IP 10.132.0.190
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Offer
            Server-ID (54), length 4: 10.132.0.190
            Lease-Time (51), length 4: 120
            RN (58), length 4: 60
            RB (59), length 4: 105
            Subnet-Mask (1), length 4: 255.255.255.252
            BR (28), length 4: 10.132.0.191
            Domain-Name (15), length 4: "home"
            Domain-Name-Server (6), length 8: 10.74.210.210,10.74.210.211
            Default-Gateway (3), length 4: 10.132.0.190
09:02:01.820762 82:62:a4:e2:85:c0 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0x45f45508, Flags [none] (0x0000)
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            Requested-IP (50), length 4: 10.132.0.189
            Server-ID (54), length 4: 10.132.0.190
            MSZ (57), length 2: 576
            Parameter-Request (55), length 8:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
            Hostname (12), length 4: "bpi4"
            Vendor-Class (60), length 12: "udhcp 1.36.1"
09:02:01.867567 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 350: (tos 0xc0, ttl 64, id 4408, offset 0, flags [none], proto UDP (17), length 336)
    192.168.1.1.67 > 10.132.0.189.68: [udp sum ok] BOOTP/DHCP, Reply, length 308, xid 0x45f45508, Flags [none] (0x0000)
          Your-IP 10.132.0.189
          Server-IP 10.132.0.190
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: ACK
            Server-ID (54), length 4: 10.132.0.190
            Lease-Time (51), length 4: 120
            RN (58), length 4: 60
            RB (59), length 4: 105
            Subnet-Mask (1), length 4: 255.255.255.252
            BR (28), length 4: 10.132.0.191
            Domain-Name (15), length 4: "home"
            Hostname (12), length 4: "bpi4"
            Domain-Name-Server (6), length 8: 10.74.210.210,10.74.210.211
            Default-Gateway (3), length 4: 10.132.0.190

Alles anzeigen

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.

kingpin42

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.

mbo77

Frustrierenderweise sieht es auf dem administrativen Netz besser aus:

Code

tcpdump: listening on br-lan.2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
09:15:45.888986 82:62:a4:e2:85:c0 > 78:c5:7d:49:d2:98, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 32690, offset 0, flags [DF], proto UDP (17), length 328)
    192.168.2.140.68 > 192.168.2.1.67: [bad udp cksum 0x8723 -> 0xa775!] BOOTP/DHCP, Request from 82:62:a4:e2:85:c0, length 300, xid 0x5804163, Flags [none] (0x0000)
          Client-IP 192.168.2.140
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Request
            MSZ (57), length 2: 576
            Parameter-Request (55), length 8:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), BR (28), NTP (42), Classless-Static-Route (121)
            Hostname (12), length 4: "bpi4"
            Vendor-Class (60), length 12: "udhcp 1.36.1"
09:15:45.951071 78:c5:7d:49:d2:98 > 82:62:a4:e2:85:c0, ethertype IPv4 (0x0800), length 346: (tos 0xc0, ttl 64, id 39775, offset 0, flags [none], proto UDP (17), length 332)
    192.168.2.1.67 > 192.168.2.140.68: [udp sum ok] BOOTP/DHCP, Reply, length 304, xid 0x5804163, Flags [none] (0x0000)
          Client-IP 192.168.2.140
          Your-IP 192.168.2.140
          Server-IP 192.168.2.1
          Client-Ethernet-Address 82:62:a4:e2:85:c0
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: ACK
            Server-ID (54), length 4: 192.168.2.1
            Lease-Time (51), length 4: 120
            RN (58), length 4: 55
            RB (59), length 4: 100
            Subnet-Mask (1), length 4: 255.255.255.0
            BR (28), length 4: 192.168.2.255
            Default-Gateway (3), length 4: 192.168.2.1
            Domain-Name (15), length 4: "home"
            Hostname (12), length 4: "bpi4"
            Domain-Name-Server (6), length 4: 192.168.2.1

Alles anzeigen

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.

mbo77

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.

::1

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.

mbo77

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.

mbo77

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.

::1

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).

Tags