[Kea-users] DHCPv4 Conflict resolution on MAC change

[Dan Oachs]

We have run into the same issue when replacing hardware.  Luckily for us
our lease times are in the range of a few hours instead of days, but it
would still be nice to have a better solution for this.

-- Dan Oachs

On Fri, Jan 27, 2023 at 7:27 AM Veronique Lefebure <
Veronique.Lefebure at cern.ch> wrote:

> 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
> --
> 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/3b0172fc/attachment-0001.htm>