Seeing Kea DHCP Issues after upgrade to 24.11
-
@3aandl Yeah we had planned to switch all devices to Kea. Got 6 in and ended up rolling 4 of them back to ISC so we stopped the project.
Biggest complaint I got was that it was re-IPing the entire network. It doesn't respect leases given out by ISC already. Then we ran into the static IP not being respected and we had to hit the brakes.
-
Problem is we cannot switch to ISC without huge pain!
We have 11 Vlans all with /24 dhcp space... so we will suffer a lot to do that.Any luck for a fix?
-
@Cylosoft said in Seeing Kea DHCP Issues after upgrade to 24.11:
Then we ran into the static IP not being respected
I have about 50 of these :
and all my device still get the same IP.
@Cylosoft said in Seeing Kea DHCP Issues after upgrade to 24.11:
Biggest complaint I got was that it was re-IPing the entire network. It doesn't respect leases given out by ISC already.
AFAIK, kea doesn't use the dhcpleases storage file ISC created.
But, as the IP pool is probably (right ?) the same, and say a device using a lease like IP 192.168.1.10 right now and wants to renew 192.168.1.10,- knowing that that at that moment, 192.168.1.10 hasn't been given away to some one (as kea just started), it will give 192.168.1.10 to 192.168.1.10No "help me" PM's please. Use the forum, the community will thank you.
Edit : and where are the logs ?? -
@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
-
@vMAC try with /tmp/kea4-ctrl-socket instead of /var/run/kea4-ctrl-socket
-
@lazaro said in Seeing Kea DHCP Issues after upgrade to 24.11:
of /var/run/kea4-ctrl-socket
That is where it is told to be / should be :
[25.03-BETA][root@pfSense.bhf.tld]/root: ll /var/run/kea4-ctrl-socket srwxr-xr-x 1 root wheel 0 Jul 2 07:46 /var/run/kea4-ctrl-socket=This :
25.03-BETA][root@pfSense.bhf.tld]/root: grep -R 'kea4-ctrl-socket' /usr/local/etc/kea/* /usr/local/etc/kea/kea-ctrl-agent.conf: "socket-name": "/tmp/kea4-ctrl-socket" /usr/local/etc/kea/kea-ctrl-agent.conf.sample: "socket-name": "/tmp/kea4-ctrl-socket" /usr/local/etc/kea/kea-dhcp4.conf: "socket-name": "/var/run/kea4-ctrl-socket" /usr/local/etc/kea/kea-dhcp4.conf.sample: "socket-name": "/tmp/kea4-ctrl-socket"tells us that, for example, the "kea-ctrl-agent" process, that uses /usr/local/etc/kea/kea-ctrl-agent.conf as its config file, is told that the shared kea4-ctrl-socket is here : /tmp/
but ... the kea-ctrl-agent process isn't sued / started by pfSense.[25.03-BETA][root@pfSense.bhf.tld]/usr/local/etc/kea: service kea status DHCPv4 server: active DHCPv6 server: active DHCP DDNS: active Control Agent: inactive Kea DHCPv4 configuration file: /usr/local/etc/kea/kea-dhcp4.conf Kea DHCPv6 configuration file: /usr/local/etc/kea/kea-dhcp6.conf Kea DHCP DDNS configuration file: /usr/local/etc/kea/kea-dhcp-ddns.conf Kea Control Agent configuration file: /usr/local/etc/kea/kea-ctrl-agent.conf keactrl configuration file: /usr/local/etc/kea/keactrl.confNote : I used the "DHCP DDNS" process also. That's of my own doing, and not yet implement in the offiacal pfSense.
