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 <[email protected]> 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 <[email protected]> On Behalf Of Darren Ankney
> Sent: Saturday, November 1, 2025 1:28 PM
> To: Kea user's list <[email protected]>
> 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 <[email protected]> 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 <[email protected]> On Behalf Of Darren Ankney
> > Sent: Sunday, October 26, 2025 4:27 AM
> > To: Kea user's list <[email protected]>
> > 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 <[email protected]> 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.
> > > [email protected]
> > --
> > 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.
> > [email protected]
> > --
> > 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.
> > [email protected]
> --
> 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.
> [email protected]
> --
> 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.
> [email protected]
-- 
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.
[email protected]

Reply via email to