17
Probleme mit KEA-DHCP-Server unter pfsense
Liebe Gemeinde,
dank der zahlreichen sehr guten Anleitungen läuft bei mir inzwischen eine pfsense-Firewall im 24/7-Betrieb. Vielen Dank dafür!
Seit ein paar Tagen habe ich jedoch ein für mich merkwürdiges Verhalten des DHCP-Servers (KEA) festgestellt. Auch eine kurze Google-Suche mit Copy&Paste der entsprechenden Log-Einträge hat leider keine Lösung gebracht. Daher poste ich meine Frage hier.
Ich nutze KEA und habe den Adress-Pool aufgespalten (von 100-144 sowie von 146-200; leider historisch über AVM gewachsen : - ) ). Nachdem die Maximum Lease Time verstrichen ist, bekommen die Clients leider nicht erneut eine IP zugewiesen – obwohl unter Lease Utilization lediglich 15% verwendet werden. Meine derzeitige Lösung ist es, die Clients bei DHCP Static Mappings einzutragen. Das ist natürlich abhängig vom Client nicht im eigentlichen Sinne des DHCP-Servers. Könnt ihr weiterhelfen?
Vielen Dank im Voraus!
dank der zahlreichen sehr guten Anleitungen läuft bei mir inzwischen eine pfsense-Firewall im 24/7-Betrieb. Vielen Dank dafür!
Seit ein paar Tagen habe ich jedoch ein für mich merkwürdiges Verhalten des DHCP-Servers (KEA) festgestellt. Auch eine kurze Google-Suche mit Copy&Paste der entsprechenden Log-Einträge hat leider keine Lösung gebracht. Daher poste ich meine Frage hier.
Ich nutze KEA und habe den Adress-Pool aufgespalten (von 100-144 sowie von 146-200; leider historisch über AVM gewachsen : - ) ). Nachdem die Maximum Lease Time verstrichen ist, bekommen die Clients leider nicht erneut eine IP zugewiesen – obwohl unter Lease Utilization lediglich 15% verwendet werden. Meine derzeitige Lösung ist es, die Clients bei DHCP Static Mappings einzutragen. Das ist natürlich abhängig vom Client nicht im eigentlichen Sinne des DHCP-Servers. Könnt ihr weiterhelfen?
Vielen Dank im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668738
Url: https://administrator.de/contentid/668738
Ausgedruckt am: 16.11.2024 um 07:11 Uhr
17 Kommentare
Neuester Kommentar
Zitat von @Frontier:
Ich nutze KEA und habe den Adress-Pool aufgespalten (von 100-144 sowie von 146-200; leider historisch über AVM gewachsen : - ) ). Nachdem die Maximum Lease Time verstrichen ist, bekommen die Clients leider nicht erneut eine IP zugewiesen
Also erstmal ist es generell so das Clients nach Ablauf der Hälfte der Lease-Time ihre Lease bei DHCP erneuern. Die Lease läuft also so lange der Client online ist nie ab, weil er sie ja schon nach der Hälfte der Zeit erneuert.Ich nutze KEA und habe den Adress-Pool aufgespalten (von 100-144 sowie von 146-200; leider historisch über AVM gewachsen : - ) ). Nachdem die Maximum Lease Time verstrichen ist, bekommen die Clients leider nicht erneut eine IP zugewiesen
Die Lease läuft also nur ab wenn der Client entweder ausgeschaltet ist oder in der Zeit keine neue Lease anfordert.
Habe das hier mit einer pfSense mal mit dem KEA DHCP Server gestestet und den Fehler nicht nachstellen können. Läuft einwandfrei. Selbst nachdem die Lease abgelaufen ist bekommen hier Clients einwandfrei eine IP.
Du solltest also mal deine DHCP-Debug Logs checken und ob deine Clients nach der Hälfte der Lease ein Paket an die Sense schicken. (TCPDump / Wireshark).
1
Vielen Dank für die Antwort.
Die grundsätzliche Vorgehensweise eines DHCP-Servers ist mit bekannt. Darüber hinaus hatte ich in der ersten Zeit auch keine Probleme.
Gerne kann ich mein Problem etwas detaillierter schildern:
1.) Der Server funktionierte in der ersten Zeit einwandfrei. An der Konfiguration habe ich nichts geändert.
2.) Natürlich tritt das Problem nur dann auf, wenn ich nach Ablauf der Lease einen Client neu starte.
3.) Ich habe den Eindruck, dass die zuvor zugewiesenen IPs nicht wieder neu verwendet werden, so dass der "Pool" nach einiger Zeit erschöpft ist.
Natürlich kann ich gerne Log-Einträge vom DHCP-Server schicken.
Die grundsätzliche Vorgehensweise eines DHCP-Servers ist mit bekannt. Darüber hinaus hatte ich in der ersten Zeit auch keine Probleme.
Gerne kann ich mein Problem etwas detaillierter schildern:
1.) Der Server funktionierte in der ersten Zeit einwandfrei. An der Konfiguration habe ich nichts geändert.
2.) Natürlich tritt das Problem nur dann auf, wenn ich nach Ablauf der Lease einen Client neu starte.
3.) Ich habe den Eindruck, dass die zuvor zugewiesenen IPs nicht wieder neu verwendet werden, so dass der "Pool" nach einiger Zeit erschöpft ist.
Natürlich kann ich gerne Log-Einträge vom DHCP-Server schicken.
Dann bitte dieses 😉
... frisch aus Status/System Logs/DHCP - nur die MAC sind durch XX ersetzt.
Noch einmal: Vielen Dank für eure Hilfe!
Noch einmal: Vielen Dank für eure Hilfe!
Oct 13 11:14:47 kea-dhcp4 51656 WARN [kea-dhcp4.alloc-engine.0xf5daee16d00] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 XX:XX:XX:XX:XX:XX], cid=[XX:XX:XX:XX:XX:XX:XX], tid=0xdab038ca: failed to allocate an IPv4 lease in the subnet 192.168.178.0/24, subnet-id 2, shared network (none)
Oct 13 11:14:47 kea-dhcp4 51656 WARN [kea-dhcp4.alloc-engine.0xf5daee16d00] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1 XX:XX:XX:XX:XX:XX], cid=[XX:XX:XX:XX:XX:XX:XX], tid=0xdab038ca: failed to allocate an IPv4 address after 100 attempt(s)
Oct 13 11:14:47 kea-dhcp4 51656 WARN [kea-dhcp4.alloc-engine.0xf5daee16d00] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 XX:XX:XX:XX:XX:XX], cid=[XX:XX:XX:XX:XX:XX:XX], tid=0xdab038ca: Failed to allocate an IPv4 address for client with classes: ALL, pool_lan_0, pool_opt3_0, pool_opt3_1, pool_opt1_0, pool_opt2_0, UNKNOWN 
Läuft einwandfrei.
Ebenso hier. Lässt sich auf 2 pfSensen mit Rel. 2.7.2, Default Leasetime 7200 und Default max. Lease 86400 und diversen unterschiedlichen DHCP Clients aller Couleur absolut nicht nachvollziehen.
Eine naive Frage - ohne die Dokumentation vorher gelesen zu haben:
Während die "richtigen" Leases unter der pfsense GUI angezeigt werden, beinhalten die Dateien dhcp4.leases und dhcp4.leases.2 noch weitere Leases. Wie es scheint, ist der "freie" Pool hier vollständig in Verwendung.
Hättet ihr noch weitere Debugging-Tipps? Wenn ich in der GUI den Knopf "Clear all DHCP Leases" drücke, dann sollten die Pools ja wieder vollständig frei sein (mit Ausnahme der gewollten Static-DHCP-Leases). Das ist natürlich keine Dauerlösung.
Mir ist wichtig zu betonen, dass ich alle Default-Werte unverändert übernommen habe.
Während die "richtigen" Leases unter der pfsense GUI angezeigt werden, beinhalten die Dateien dhcp4.leases und dhcp4.leases.2 noch weitere Leases. Wie es scheint, ist der "freie" Pool hier vollständig in Verwendung.
Hättet ihr noch weitere Debugging-Tipps? Wenn ich in der GUI den Knopf "Clear all DHCP Leases" drücke, dann sollten die Pools ja wieder vollständig frei sein (mit Ausnahme der gewollten Static-DHCP-Leases). Das ist natürlich keine Dauerlösung.
Mir ist wichtig zu betonen, dass ich alle Default-Werte unverändert übernommen habe.
Dein Pool ist wohl dicht ...
https://github.com/isc-projects/kea/blob/master/src/lib/dhcpsrv/alloc_en ...
Da spamt dir vermutlich irgendein Client mit random client_ids den Pool voll.
Also mal testweise client_id matching ignorieren lassen.
"match-client-id": false
Wir kennen die Anzahl deiner Gerätschaften und Leases nicht , aber wenn der Pool voll ist ist er eben voll. Dann musst du ihnen entweder wieder freischaufeln , vergrößern oder die Lease-Time verringern.
Wireshark und die MACs der vergebenen Leases sollten dir zeigen wer da im Netz rum spammt.
https://github.com/isc-projects/kea/blob/master/src/lib/dhcpsrv/alloc_en ...
Da spamt dir vermutlich irgendein Client mit random client_ids den Pool voll.
Also mal testweise client_id matching ignorieren lassen.
"match-client-id": false
Wir kennen die Anzahl deiner Gerätschaften und Leases nicht , aber wenn der Pool voll ist ist er eben voll. Dann musst du ihnen entweder wieder freischaufeln , vergrößern oder die Lease-Time verringern.
Wireshark und die MACs der vergebenen Leases sollten dir zeigen wer da im Netz rum spammt.
1
Und wenn es dann immer noch Probleme gibt: leere den Pool und hänge die Clients einzeln ins Netz, um zu testen, wer sich da in kurzer Zeit so viele Adressen zieht.
1
@150704, @DivideByZero : Danke für die Rückmeldung
Ich hatte ja bereist erwähnt, dass ich
durchgeführt habe. Dabei bin ich auch auf die Seite
gestoßen. Die Informationen grenzen den Fehler jedoch nur sehr schwach ein. Ebenso hatte ich bereits geschrieben, dass ich zur Not den Pool löschen werde. Ich halte dieses Vorgehen jedoch nicht für besonders effizient - ebenso nicht die Clients danach einzeln in das Netz zu integrieren. Gibt es kein effizienteres Vorgehen bzw. aussagekräftigere Log-Files?
Ich hatte ja bereist erwähnt, dass ich
eine kurze Google-Suche mit Copy&Paste der entsprechenden Log-Einträge
durchgeführt habe. Dabei bin ich auch auf die Seite
gestoßen. Die Informationen grenzen den Fehler jedoch nur sehr schwach ein. Ebenso hatte ich bereits geschrieben, dass ich zur Not den Pool löschen werde. Ich halte dieses Vorgehen jedoch nicht für besonders effizient - ebenso nicht die Clients danach einzeln in das Netz zu integrieren. Gibt es kein effizienteres Vorgehen bzw. aussagekräftigere Log-Files?
Ebenso hatte ich bereits geschrieben, dass ich zur Not den Pool löschen werde. Ich halte dieses Vorgehen jedoch nicht für besonders effizient - ebenso nicht die Clients danach einzeln in das Netz zu integrieren. Gibt es kein effizienteres Vorgehen bzw. aussagekräftigere Log-Files?
Doch, ist sehr effizient, es sei denn, Du hast hunderte Clients. Über Dein Netz wissen wir ja nichts. Aber so könntest Du dem Problem schnell auf die Spur kommen.
1
Noch einmal: Danke für eure Hilfe!
Da anscheinend keine neue, effektiveren Ideen geposted werden, schließe ich den Beitrag und verteile die Punkte : - )
Da anscheinend keine neue, effektiveren Ideen geposted werden, schließe ich den Beitrag und verteile die Punkte : - )
Auch bei der OPNsense rennt der KEA ziemlich fehlerhaft. Siehe dazu HIER.
In komplexen Netzwerk Settings sollte man von einem Einsatz derzeit besser absehen und den bewährten ISC nutzen.
In komplexen Netzwerk Settings sollte man von einem Einsatz derzeit besser absehen und den bewährten ISC nutzen.
@aqui: Danke! Das ist der erste Post, der sich mit meiner ursprünglichen Google-Suche deckt.
Wenn ich von KEA auf ISC umstelle, bleiben dann die "static mappings" und die Pools erhalten? Meine Frage ist also, ob die Umstellung minimalinvasiv und mit einem "Klick" erledigt ist.
Wenn ich von KEA auf ISC umstelle, bleiben dann die "static mappings" und die Pools erhalten? Meine Frage ist also, ob die Umstellung minimalinvasiv und mit einem "Klick" erledigt ist.
Leider nicht! Ich bin von einem KEA Setup wegen der massiven Fehlfunktion auf einem getaggten LACP LAG wieder auf ISC zurückgegangen.
Die statischen Mac Einträge werden erwartungsgemäß an einem ganz anderen Menüpunkt eingetragen, da die Settings bei KEA und ISC immer auf diese selber bezogen sind. Es kommt NICHT vor das ISC Settings Einstellungen von KEA nutzen und vice versa. Das ist erwartungsgemäß vollkommen getrennt.
Mit dem Stoppen bzw. Deaktivieren des KEA Daemons verschwinden dann auch die statischen Einträge. Im Hinblick auf eine saubere Konfig sollte man diese so oder so immer löschen so das nicht ggf. vorhandene Konfig "Reste" negative Wechselwirkungen bedingen.
Das Einzige was man machen kann ist sie vorab per Cut and Paste ins ISC Setup zu übertragen bevor man sie bei KEA löscht. Das klappt natürlich problemlos.
Die statischen Mac Einträge werden erwartungsgemäß an einem ganz anderen Menüpunkt eingetragen, da die Settings bei KEA und ISC immer auf diese selber bezogen sind. Es kommt NICHT vor das ISC Settings Einstellungen von KEA nutzen und vice versa. Das ist erwartungsgemäß vollkommen getrennt.
Mit dem Stoppen bzw. Deaktivieren des KEA Daemons verschwinden dann auch die statischen Einträge. Im Hinblick auf eine saubere Konfig sollte man diese so oder so immer löschen so das nicht ggf. vorhandene Konfig "Reste" negative Wechselwirkungen bedingen.
Das Einzige was man machen kann ist sie vorab per Cut and Paste ins ISC Setup zu übertragen bevor man sie bei KEA löscht. Das klappt natürlich problemlos.
@aqui: Danke! Das waren die Antworten, die ich gesucht habe! Dennoch verstehe ich nicht so ganz, wie eine solche KEA-Implementierung als Default in pfSense verwendet wird.
Default ist es ja nicht bzw. der ISC ist es weiterhin in pfSense und OPNsense. Man muss es ja immer explizit auswählen wenn man es will.
Die Frage ist aber berechtigt bei soviel Fehler. Ist ja auch nicht auf pfSense limitiert.
Die Frage ist aber berechtigt bei soviel Fehler. Ist ja auch nicht auf pfSense limitiert.
Hier ist ISC immer noch der Default bei einer Neueinrichtung, sofern du es nicht explizit selbst änderst ...
1
