We would have the same use-case as you, Tobi, and I guess we would not be the only ones ? The problem is also mentioned on https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag by the way.
On https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations doc says "The best way to avoid such a recovery is not to define new reservations that conflict with existing leases. Another recommendation is to use out-of-pool reservations; if the reserved address does not belong to a pool, there is no way that other clients can get it." But indeed, even with out-of-pool reservations, the hardware replacement use-case is not going to work :-/ ________________________________ From: Kea-users <[email protected]> on behalf of GIRSTMAIR Tobias via Kea-users <[email protected]> Sent: Friday, January 27, 2023 1:07 PM To: [email protected] <[email protected]> Subject: [Kea-users] DHCPv4 Conflict resolution on MAC change Hi all, We recently migrated to Kea 2.2.0 and now ran into the following situation: Initially: - Leases are valid for a long time (11 days, per customer requirement) - There is a host reservation for <mac1> and <ip1> - The device with <mac1> got a lease for <ip1> Now, the hardware is replaced and the reservation is updated, so the new device gets the same IP: - remove reservation for <mac1> and <ip1> - add reservation for <mac2> and <ip1> - the old device is unplugged, and therefore cannot release its lease - the new device is plugged in and requests a lease Now, Kea looks for the host reservation for <mac2> and notices that <ip1> is still leased to <mac1>, so it refuses to reassign this IP. This looks like this in the log: 2023-01-26 08:43:18.065 WARN [kea-dhcp4.alloc- engine/1409.139836331153152] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 00:15:bc:28:2b:0c], cid=[01:00:15:bc:28:2b:0c], tid=0xaf01221b: conflicting reservation for address 10.58.166.192 with existing lease Address: 10.58.166.192 Valid life: 950400 Cltt: 1674552388 Hardware addr: 00:15:bc:28:09:e7 Client id: 01:00:15:bc:28:09:e7 Subnet ID: 5164 State: default I read through section 8.3.2 of the documentation, and the conflict resolution protocol used seems to not handle our case here (where the old device doesn't release its lease). It expects the old device with <mac1> to renew its lease, before responding with DHCPNAK and reallocating <ip1> to <mac2>. As a workaround, an operator could manually delete the lease with kea- shell (or its underlying api), but that does not scale to our size. The documentation describes that "A naive approach would to be immediately remove the existing lease for Host A and create a new one for Host B" -- this would be exactly what we want, and what our previous setup did. Our reservations are out-of-pool, and we can be certain that when the MAC of a reservation changes, the old device will not be online any longer. Is there a way to achieve this? Thanks, Tobi -- 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 mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
-- 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 mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
