[Kea-users] Kea offering multiple different IP addresses to same client
Ben Bridges
bbridges at springnet.net
Fri Nov 21 23:00:47 UTC 2025
Hi Darren,
Thanks for that additional information. I didn't see that in the manual.
.Ben Bridges.
-----Original Message-----
From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of Darren Ankney
Sent: Wednesday, November 19, 2025 8:41 AM
To: Kea user's list <kea-users at lists.isc.org>
Subject: Re: [Kea-users] Kea offering multiple different IP addresses to same client
Hi Ben,
A colleague points out that I was incorrect and this is covered in the
ARM here: https://kea.readthedocs.io/en/stable/arm/dhcp4-srv.html#iterative-allocator
where it says:
"It remembers the last offered address and offers this address,
increased by one, to the next client."
Since your client never completed the DORA process, it is essentially
the "next client". You can only work around this by setting
"offer-lifetime" to some big enough number that the returning client
should get offered the same address again. This really shouldn't be
necessary, however. If you want a client to get a specific address,
there is the "reservations" mechanism that allows you to set an
address for the client.
Thank you,
Darren Ankney
On Wed, Nov 12, 2025 at 2:11 PM Ben Bridges <bbridges at springnet.net> wrote:
>
> Hi Darren,
>
> Even with severity set to DEBUG and debuglevel set to 99, the server still gives absolutely no indication in the logs why it offers a different IP address for each DISCOVER. It simply reports that it is doing so. I'm assuming there's some sort of pseudo round robin algorithm in Kea for deciding what IP address to offer, but that's pure conjecture on my part. I wish ISC would document this behavior since it is different than their older DHCP server (and arguably different than what one might expect).
>
> I did change the pool size from 10 addresses to 2 addresses, and Kea rotated back and forth between them for each DISCOVER. So this "round robin" behavior doesn't keep the client from eventually getting an IP address.
>
> Thanks,
> .Ben Bridges.
>
> -----Original Message-----
> From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of Darren Ankney
> Sent: Thursday, November 6, 2025 1:52 PM
> To: Kea user's list <kea-users at lists.isc.org>
> Subject: Re: [Kea-users] Kea offering multiple different IP addresses to same client
>
> Hi Ben,
>
> At this point, looking at logs would be the way forward. As I said
> previously, Kea should not be offering a different address unless the
> previous address was in use. if you set "severity": "DEBUG", and
> "debuglevel": 99 in your "loggers" section, then Kea will print
> details about the address selection process to
> "/var/log/kea/kea-dhcp4.log". This may not completely answer the
> question but might. If this is a busy production server, you may not
> want to do this, however.
>
> Thank you,
> Darren Ankney
>
> On Tue, Nov 4, 2025 at 6:23 PM Ben Bridges <bbridges at springnet.net> wrote:
> >
> > Hi Darren,
> >
> > There is only one client in this subnet. There are no other DISCOVERs coming from any other devices. If Kea is expected to keep offering 10.255.237.201 to clients until a client completes a DORA for the address, why is Kea offering different IP addresses to this one client? (This behavior appears to be different than ISC's older DHCP server.)
> >
> > Thanks,
> > .Ben Bridges.
> >
> > -----Original Message-----
> > From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of Darren Ankney
> > Sent: Saturday, November 1, 2025 1:28 PM
> > To: Kea user's list <kea-users at lists.isc.org>
> > Subject: Re: [Kea-users] Kea offering multiple different IP addresses to same client
> >
> > Hi Ben,
> >
> > It looks like you are accepting all of the defaults. The allocator
> > will be "iterative". That matches with the ip addresses counting up
> > in your offers. I am not sure if this will prevent the behavior you
> > are seeing, but try setting "offer-lifetime": 60, in your subnet (see
> > here: https://kea.readthedocs.io/en/kea-2.6.4/arm/dhcp4-srv.html#temporary-allocation-on-dhcpdiscover).
> > This parameter might cause Kea to persistently offer this same address
> > to this same client.
> >
> > Kea should be offering the next IP address that is available. I
> > assume other clients are not being allocated the address that was
> > previously offered in between DISCOVERS from this client? Otherwise,
> > if no client is using 10.255.237.201 then each client that sends a
> > discover should be offered this same address until someone completes
> > the DORA for the address.
> >
> > Thank you,
> > Darren Ankney
> >
> > On Mon, Oct 27, 2025 at 8:12 PM Ben Bridges <bbridges at springnet.net> wrote:
> > >
> > > Hi Darren,
> > >
> > > Thanks for responding. Below is the configuration:
> > >
> > > {
> > > "Dhcp4": {
> > > "interfaces-config": {
> > > "interfaces": [ "ens3" ]
> > > },
> > >
> > > "control-socket": {
> > > "socket-type": "unix",
> > > "socket-name": "kea4-ctrl-socket"
> > > },
> > >
> > > "lease-database": {
> > > "type": "memfile",
> > > "lfc-interval": 3600
> > > },
> > >
> > > "expired-leases-processing": {
> > > "reclaim-timer-wait-time": 10,
> > > "flush-reclaimed-timer-wait-time": 25,
> > > "hold-reclaimed-time": 3600,
> > > "max-reclaim-leases": 100,
> > > "max-reclaim-time": 250,
> > > "unwarned-reclaim-cycles": 5
> > > },
> > >
> > > "valid-lifetime": 7200,
> > >
> > > "option-data": [
> > > {
> > > "name": "domain-name-servers",
> > > "data": "10.1.1.1, 10.2.1.1"
> > > },
> > > {
> > > "name": "tftp-server-name",
> > > "data": "10.2.1.9"
> > > },
> > > {
> > > "name": "boot-file-name",
> > > "data": "boot.file"
> > > },
> > > ],
> > >
> > > "client-classes": [
> > > {
> > > "name": "Test-Clients",
> > > "test": "substring(option[60].hex,0,13) == '<redacted>'",
> > > }
> > > ],
> > >
> > > "hooks-libraries": [
> > > {
> > > "library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
> > > },
> > > ],
> > >
> > > "subnet4": [
> > > {
> > > "id": 50,
> > > "subnet": "10.255.237.0/24",
> > > "pools": [ { "pool": "10.255.237.201 - 10.255.237.210", "client-class": "Test-Clients"} ],
> > > "option-data": [
> > > {
> > > "name": "routers",
> > > "data": "10.255.237.1"
> > > }
> > > ]
> > > }
> > > ],
> > >
> > > "loggers": [
> > > {
> > > "name": "kea-dhcp4",
> > > "output-options": [
> > > {
> > > "output": "/var/log/kea/kea-dhcp4.log",
> > > "maxver": 8
> > > }
> > > ],
> > > "severity": "INFO",
> > > "debuglevel": 0
> > > }
> > > ]
> > > }
> > > }
> > >
> > > Thanks,
> > > .Ben Bridges.
> > >
> > > -----Original Message-----
> > > From: Kea-users <kea-users-bounces at lists.isc.org> On Behalf Of Darren Ankney
> > > Sent: Sunday, October 26, 2025 4:27 AM
> > > To: Kea user's list <kea-users at lists.isc.org>
> > > Subject: Re: [Kea-users] Kea offering multiple different IP addresses to same client
> > >
> > > Hi Ben,
> > >
> > > It is not possible to answer this question without seeing your
> > > configuration. Generally speaking, the chosen lease allocator should
> > > have the most influence regarding what IP address is offered. See
> > > here: https://kea.readthedocs.io/en/kea-3.0.1/arm/dhcp4-srv.html#allocators-comparison
> > > of course offer lifetime (as you mention) could have some influence as
> > > well: https://kea.readthedocs.io/en/kea-3.0.1/arm/dhcp4-srv.html#temporary-allocation-on-dhcpdiscover
> > >
> > > Thank you,
> > > Darren Ankney
> > >
> > > On Fri, Oct 17, 2025 at 8:13 PM Ben Bridges <bbridges at springnet.net> wrote:
> > > >
> > > > Greetings.
> > > >
> > > >
> > > >
> > > > My apologies if this has been asked and answered before. I did not find a thread on this subject in the archives of this list, but it seems like the sort of thing that might have been asked before.
> > > >
> > > >
> > > >
> > > > We have some devices which prefer to receive DHCP offers from the DHCP server made by the same manufacturer as the clients. They ignore the first four offers made by other DHCP servers and then finally accept/request the fifth offer. When the DHCP DISCOVER packets from one of these devices are relayed to a Kea 2.6 server, Kea offers the device a different IP address in response to each of the five DISCOVER packets. Is this by design? The DISCOVER packets all appear to be identical except for the Transaction ID and Seconds Elapsed. Why isn’t Kea offering the same IP address to the client every time? This is a test situation with only one device in the subnet, so there are no DHCP packets from any other devices. “offer-lifetime” is not configured for the subnet and hence should be 0, but it seems to me that the purpose of the “offer-lifetime” parameter is probably to be able to offer the same IP address to a device sending multiple requests in the presence of requests from other devices. There are no other requests in this case.
> > > >
> > > >
> > > >
> > > > Below are the logs showing the receipt of the DISCOVER packets and the subsequent offers by Kea:
> > > >
> > > >
> > > >
> > > > 2025-10-14 08:05:54.776 INFO [kea-dhcp4.packets/659.140495010055744] DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x67458b6b: DHCPDISCOVER (type 1) received from 10.255.237.1 to <redacted> on interface ens3
> > > >
> > > > 2025-10-14 08:05:54.777 INFO [kea-dhcp4.leases/659.140495010055744] DHCP4_LEASE_OFFER [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x67458b6b: lease 10.255.237.201 will be offered
> > > >
> > > > 2025-10-14 08:05:58.820 INFO [kea-dhcp4.packets/659.140495018448448] DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0xc6237b32: DHCPDISCOVER (type 1) received from 10.255.237.1 to <redacted> on interface ens3
> > > >
> > > > 2025-10-14 08:05:58.820 INFO [kea-dhcp4.leases/659.140495018448448] DHCP4_LEASE_OFFER [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0xc6237b32: lease 10.255.237.202 will be offered
> > > >
> > > > 2025-10-14 08:06:06.776 INFO [kea-dhcp4.packets/659.140495010055744] DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x69983c64: DHCPDISCOVER (type 1) received from 10.255.237.1 to <redacted> on interface ens3
> > > >
> > > > 2025-10-14 08:06:06.776 INFO [kea-dhcp4.leases/659.140495010055744] DHCP4_LEASE_OFFER [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x69983c64: lease 10.255.237.203 will be offered
> > > >
> > > > 2025-10-14 08:06:14.781 INFO [kea-dhcp4.packets/659.140495018448448] DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x73483366: DHCPDISCOVER (type 1) received from 10.255.237.1 to <redacted> on interface ens3
> > > >
> > > > 2025-10-14 08:06:14.781 INFO [kea-dhcp4.leases/659.140495018448448] DHCP4_LEASE_OFFER [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x73483366: lease 10.255.237.204 will be offered
> > > >
> > > > 2025-10-14 08:06:22.784 INFO [kea-dhcp4.packets/659.140495010055744] DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x51dcb074: DHCPDISCOVER (type 1) received from 10.255.237.1 to <redacted> on interface ens3
> > > >
> > > > 2025-10-14 08:06:22.784 INFO [kea-dhcp4.leases/659.140495010055744] DHCP4_LEASE_OFFER [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x51dcb074: lease 10.255.237.205 will be offered
> > > >
> > > > 2025-10-14 08:06:25.733 INFO [kea-dhcp4.packets/659.140495018448448] DHCP4_PACKET_RECEIVED [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x51dcb074: DHCPREQUEST (type 3) received from 10.255.237.1 to <redacted> on interface ens3
> > > >
> > > > 2025-10-14 08:06:25.733 INFO [kea-dhcp4.leases/659.140495018448448] DHCP4_LEASE_ALLOC [hwtype=1 xx:xx:xx:39:09:b5], cid=[01:xx:xx:xx:39:09:b5], tid=0x51dcb074: lease 10.255.237.205 has been allocated for 7200 seconds
> > > >
> > > >
> > > >
> > > > I redacted part of each of the Client Identifiers, but they are all identical (as are the hardware addresses).
> > > >
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > .Ben Bridges.
> > > >
> > > > --
> > > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> > > >
> > > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > > > Kea-users at lists.isc.org
> > > --
> > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> > >
> > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > > Kea-users at lists.isc.org
> > > --
> > > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> > >
> > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > > Kea-users at lists.isc.org
> > --
> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> >
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > Kea-users at lists.isc.org
> > --
> > ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> >
> > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> > Kea-users at lists.isc.org
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org
> --
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
> Kea-users at lists.isc.org
--
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users at lists.isc.org
More information about the Kea-users
mailing list