[Kea-users] DHCPv4 Conflict resolution on MAC change

[Veronique Lefebure]

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 <kea-users-bounces at lists.isc.org> on behalf of GIRSTMAIR Tobias via Kea-users <kea-users at lists.isc.org>
Sent: Friday, January 27, 2023 1:07 PM
To: kea-users at lists.isc.org <kea-users at lists.isc.org>
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
Kea-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230127/5d16089d/attachment-0001.htm>