Re: [Kea-users] Kea offering multiple different IP addresses to same client
Hi Darren, Thanks for that additional information. I didn't see that in the manual. .Ben Bridges. -Original Message- From: Kea-users On Behalf Of Darren Ankney Sent: Wednesday, November 19, 2025 8:41 AM To: Kea user's list 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 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 On Behalf Of Darren Ankney > Sent: Thursday, November 6, 2025 1:52 PM > To: Kea user's list > 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 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 On Behalf Of Darren Ankney > > Sent: Saturday, November 1, 2025 1:28 PM > > To: Kea user's list > > 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 wrote: > >
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 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 On Behalf Of Darren Ankney
> Sent: Thursday, November 6, 2025 1:52 PM
> To: Kea user's list
> 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 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 On Behalf Of Darren Ankney
> > Sent: Saturday, November 1, 2025 1:28 PM
> > To: Kea user's list
> > 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 wrote:
> > >
> > > Hi Darren,
> > >
> > > Thanks for responding. Below is the configuration:
> > >
> > > {
> > > "Dhcp4": {
> > > "interfaces-config": {
> > > "interfaces": [ "ens3" ]
> >
Re: [Kea-users] Kea offering multiple different IP addresses to same client
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 On Behalf Of Darren Ankney
Sent: Thursday, November 6, 2025 1:52 PM
To: Kea user's list
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 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 On Behalf Of Darren Ankney
> Sent: Saturday, November 1, 2025 1:28 PM
> To: Kea user's list
> 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 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"
> > },
> > {
> >
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 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 On Behalf Of Darren Ankney
> Sent: Saturday, November 1, 2025 1:28 PM
> To: Kea user's list
> 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 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) == ''",
> > }
> > ],
> >
> > "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"} ],
Re: [Kea-users] Kea offering multiple different IP addresses to same client
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 On Behalf Of Darren Ankney
Sent: Saturday, November 1, 2025 1:28 PM
To: Kea user's list
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 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) == ''",
> }
> ],
>
> "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 On Behalf Of Darren Ankney
> Sent: Sunday, October 26, 2025 4:27 AM
> To: Kea user's list
> 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
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 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) == ''",
> }
> ],
>
> "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 On Behalf Of Darren Ankney
> Sent: Sunday, October 26, 2025 4:27 AM
> To: Kea user's list
> 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 wrote:
> >
> > Greetings.
> >
> >
> >
> > My apologies if this has been asked and answere
Re: [Kea-users] Kea offering multiple different IP addresses to same client
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) == ''",
}
],
"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 On Behalf Of Darren Ankney
Sent: Sunday, October 26, 2025 4:27 AM
To: Kea user's list
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 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_PAC
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 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 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 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 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 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 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 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. >
