<div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-- Dan Oachs<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 27, 2023 at 7:27 AM Veronique Lefebure <<a href="mailto:Veronique.Lefebure@cern.ch">Veronique.Lefebure@cern.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg3498965003900284039">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
We would have the same use-case as you, Tobi, and I guess we would not be the only ones ?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
The problem is also mentioned on <a href="https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag" title="https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag" id="m_3498965003900284039LPlnk921418" target="_blank">https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=replace-client-id#the-replace-client-id-flag</a> by
the way.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
On <a href="https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations" title="https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations" id="m_3498965003900284039LPlnk630249" target="_blank">https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html?#conflicts-in-dhcpv4-reservations</a> doc
says </div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span> </span>"<span style="color:rgb(64,64,64);font-family:Lato,proxima-nova,"Helvetica Neue",Arial,sans-serif;background-color:rgb(252,252,252);display:inline">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.</span>" </div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
But indeed, even with out-of-pool reservations, the hardware replacement use-case is not going to work :-/</div>
<div id="m_3498965003900284039appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_3498965003900284039divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Kea-users <<a href="mailto:kea-users-bounces@lists.isc.org" target="_blank">kea-users-bounces@lists.isc.org</a>> on behalf of GIRSTMAIR Tobias via Kea-users <<a href="mailto:kea-users@lists.isc.org" target="_blank">kea-users@lists.isc.org</a>><br>
<b>Sent:</b> Friday, January 27, 2023 1:07 PM<br>
<b>To:</b> <a href="mailto:kea-users@lists.isc.org" target="_blank">kea-users@lists.isc.org</a> <<a href="mailto:kea-users@lists.isc.org" target="_blank">kea-users@lists.isc.org</a>><br>
<b>Subject:</b> [Kea-users] DHCPv4 Conflict resolution on MAC change</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>Hi all,<br>
<br>
We recently migrated to Kea 2.2.0 and now ran into the following<br>
situation:<br>
<br>
Initially:<br>
- Leases are valid for a long time (11 days, per customer requirement)<br>
- There is a host reservation for <mac1> and <ip1><br>
- The device with <mac1> got a lease for <ip1><br>
<br>
Now, the hardware is replaced and the reservation is updated, so the<br>
new device gets the same IP:<br>
- remove reservation for <mac1> and <ip1><br>
- add reservation for <mac2> and <ip1><br>
- the old device is unplugged, and therefore cannot release its lease<br>
- the new device is plugged in and requests a lease<br>
<br>
Now, Kea looks for the host reservation for <mac2> and notices that<br>
<ip1> is still leased to <mac1>, so it refuses to reassign this IP.<br>
This looks like this in the log:<br>
<br>
2023-01-26 08:43:18.065 WARN [kea-dhcp4.alloc-<br>
engine/1409.139836331153152] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT<br>
[hwtype=1 00:15:bc:28:2b:0c], cid=[01:00:15:bc:28:2b:0c],<br>
tid=0xaf01221b: conflicting reservation for address 10.58.166.192 with<br>
existing lease Address: 10.58.166.192<br>
Valid life: 950400<br>
Cltt: 1674552388<br>
Hardware addr: 00:15:bc:28:09:e7<br>
Client id: 01:00:15:bc:28:09:e7<br>
Subnet ID: 5164<br>
State: default<br>
<br>
I read through section 8.3.2 of the documentation, and the conflict<br>
resolution protocol used seems to not handle our case here (where the<br>
old device doesn't release its lease). It expects the old device with<br>
<mac1> to renew its lease, before responding with DHCPNAK and<br>
reallocating <ip1> to <mac2>.<br>
<br>
As a workaround, an operator could manually delete the lease with kea-<br>
shell (or its underlying api), but that does not scale to our size.<br>
<br>
The documentation describes that "A naive approach would to be<br>
immediately remove the existing lease for Host A and create a new one<br>
for Host B" -- this would be exactly what we want, and what our<br>
previous setup did. Our reservations are out-of-pool, and we can be<br>
certain that when the MAC of a reservation changes, the old device will<br>
not be online any longer. Is there a way to achieve this?<br>
<br>
Thanks,<br>
<br>
Tobi<br>
-- <br>
ISC funds the development of this software with paid support subscriptions. Contact us at
<a href="https://www.isc.org/contact/" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
To unsubscribe visit <a href="https://lists.isc.org/mailman/listinfo/kea-users" target="_blank">
https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org" target="_blank">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</div>
</span></font></div>
</div>
-- <br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
To unsubscribe visit <a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a>.<br>
<br>
Kea-users mailing list<br>
<a href="mailto:Kea-users@lists.isc.org" target="_blank">Kea-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/kea-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/kea-users</a><br>
</div></blockquote></div>