Seeing Kea DHCP Issues after upgrade to 24.11
-
@Gertjan said in Seeing Kea DHCP Issues after upgrade to 24.11:
AFAIK, kea doesn't use the dhcpleases storage file ISC created.
dhcpleases will die along with ISC DHCPD. It is not used with Kea.
-
@Gertjan Yeah static mappings work. Except when they don't. This particular network has 91 static mappings. 90 of them had no issue. The VM with an issue rebooted once and got it's correct static IP back, then the next reboot it got one from the pool. Then I forced several more reboots and it kept pulling the next pool IP. I actually deleted the static mapping and recreated, rebooted and it pulled the static, then I rebooted again and it got one from the pool. I should have taken a screenshot with the same MAC having a bunch of IPs consumed, but it was causing issues so no time for that.
After switching from ISC to Kea I fully expected Kea to give out the same lease when the client did a renewal request. On the 6 networks we did it was always that every renewal request started from the first available on the pool and went up. So on every network we had issues with duplicate IPs. Then we had to cycle switches and APs to get that quickly cleaned up. Then you get a few people doing things by IP that shouldn't be "but the IP never has changed in years". So complaints about the entire network being re-IP'd.
I agree it should be if we had 192.168.1.10 to 192.168.1.100 as a pool and the client requests 192.168.1.80 as a renewal it gets 192.168.1.80 if that's not already used. But Kea forces it down to 192.168.1.10. So then you get a duplicate IP issue for a bit.
It happened twice and I actually told my guy he must be wrong because I was sure ISC would have given out the requested IP again and no way would Kea be setup to not do that. I switched 4 of the networks myself and saw it every time.
-
@Cylosoft Same here, as we dug in, we saw several times where leases that were assigned elsewhere were given to another device etc. The crazy part is there were still IP's available in the pool when it started flooding the logs and no longer handing out addresses. In most cases KEA seemed to hand out the next IP in the pool to a device and if it is rebooted etc. it would pull the next one so it seemed like one MAC may have 4-5 IP's etc. tied to it.
-
@cmcdonald Don't they use "Host Reservations" in KEA which from what I understand are basically the same thing or am I not understanding this correctly?
https://kb.isc.org/docs/what-are-host-reservations-how-to-use-them
-
@3aandl said in Seeing Kea DHCP Issues after upgrade to 24.11:
https://kb.isc.org/docs/what-are-host-reservations-how-to-use-them
That's what my /usr/local/etc/kea/kea-dhcp4.conf shows :
"reservations": [ { "hw-address": "00:4e:01:ca:ca:9c", "ip-address": "192.168.1.2", "hostname": "bureau2" }, { "hw-address": "ac:15:a2:42:b0:0b", "ip-address": "192.168.1.3", "hostname": "TL-SG108E" }, { "hw-address": "00:15:71:f6:ce:77", "ip-address": "192.168.1.4", "hostname": "poweredget310" }, ....... -
@ysam We had 7 VLANS here that were all /24 and we had no issues switching back. It is possible you may see a few hiccups as things renew IPs but overall, it was not a big deal. We also had boatloads of static leases.
-
@3aandl Yup, you're right, we tested switching back standby pfsense and all went smooth so we also switched primary as well, no issues, but we also lost HA dhcp as well so now we stopped dhcp on standby for now..
-
Is there a solution to this, as this is now the second time that this has happened in my network and I don't remember what the original solution was/is. I had this happen about 6 months ago and I think to fix it I just had to bump up the size of the subnet.
I tried the below online and via putty and it doesn't generate any logs or outputs that I could find.
@cmcdonald said in Seeing Kea DHCP Issues after upgrade to 24.11:
@3aandl can you run at
Diagnostics > Command Promptecho '{"command":"config-get"}' | nc -U /var/run/kea4-ctrl-socket | jqand
echo '{"command":"lease4-get-all"}' | nc -U /var/run/kea4-ctrl-socket | jq -
@vMAC I never heard anything back after uploading the files and from reading several forums it seems there are still a number of issues with KEA and it does not seem to be ready for "primetime". All of my issues disappeared after moving back to ISC
-
@vMAC said in Seeing Kea DHCP Issues after upgrade to 24.11:
echo '{"command":"config-get"}' | nc -U /var/run/kea4-ctrl-socket | jq
and
echo '{"command":"lease4-get-all"}' | nc -U /var/run/kea4-ctrl-socket | jq
doesn't return a lot of info for you ?
Wow .... not 'normal'.
Actually, the process kea-ctrl (the kea control process) isn't listening to its "socket" for commands (you send to it using the commands shown above).
It stopped running, or the socket is disconnected for 'some reason'.When I execute - onsodle or SSH ! - both commands shown, I receive a lot of info : the running state of the kea processes.
Knowing that I severally modified the official config 24.11 kea IPv4 and IPv4 servers, and the control process "for testing new, not yet official implemented capabilities" see here and this was last week, and kea, all the process, are rock solid.
I even have a new process now : kea-dhcp-ddns for my personal amusement (DNS IPv6 updates and reverse PTR updates) :[24.11-RELEASE][root@pfSense.bhf.tld]/root: ps ax | grep 'kea' 30883 - S 0:18.55 /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf 31322 - S 0:06.73 /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf 37777 0- I 0:02.07 /usr/local/sbin/kea-dhcp-ddns -c /usr/local/etc/kea/kea-dhcp-ddns.conf 41629 0- I 0:00.08 /usr/local/sbin/kea-ctrl-agent -c /usr/local/etc/kea/kea-ctrl-agent.confTrue, this concerns 24.11, and I'm very happy about it.
As good as ISC for me right now (touch wood).Btw : My setup is pretty vanilla.
No VLAN's, just 3 classic LANs
LAN : 192.168.1.1/24 with a pool 192.168.1.100 -> 192.168.1.250 - most of my devices use static MAC DHCP leases - two APs, a couple of (my own) wifi devices.
LAN 2 : 192.168.2.1/24 with a pool 192.168.1.10 -> 192.168.1.250 - just 5 static leases (switch and 4 APs), as this is a captive portal. The rest is pool based = my captive portal visitors. Mostly wifi devices.
LAN 3 : 192.168.3.1/24 some others stuff. Only a DHCP pool, not many devices. -
M mcury referenced this topic on
