<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<div id="rwhMsgHeader">Thanks. This is all I've been able to find
as well.... Seems like such a hack - and not something that
would work on any high traffic subnet unless the lease times
were quite short to begin with.</div>
<div><br>
</div>
<div>Just seems like this should be a simple boolean flag "record
any released lease as expired" to get it to feed into existing
reclaim mechanism. <br>
</div>
<div><br>
</div>
<div>I saw a mail thread where "compliance with the protocol" was
raised as a concern, but I don't see how the spec says "dhcp
server MUST give a different address" or anything about how the
dhcp server should pick between it's pools of addresses, that to
me is purely a preference/ordering choice of the software.
Actually ignoring/dropping DHCPRELEASE does seem like a protocol
violation.<br>
</div>
<div><br>
</div>
<div>-- Nathan</div>
<div><br>
<hr id="rwhMsgHdrDivider" style="border:0;border-top:1px solid
#B5C4DF;padding:0;margin:10px 0 5px 0;width:100%;">
<div style="font-family:Tahoma !important; color:#000000
!important; font-size:13px !important;"><b>From:</b> Blažej
Krajňák [<a class="moz-txt-link-freetext" href="mailto:blazej.krajnak@gmail.com">mailto:blazej.krajnak@gmail.com</a>]</div>
<div style="font-family:Tahoma !important; color:#000000
!important; font-size:13px !important;"><b>Sent:</b> Saturday,
October 8, 2022 at 4:03 AM</div>
<div style="font-family:Tahoma !important; color:#000000
!important; font-size:13px !important;"><b>To:</b> Nathan
Neulinger <a class="moz-txt-link-rfc2396E" href="mailto:nneul@neulinger.org"><nneul@neulinger.org></a></div>
<div style="font-family:Tahoma !important; color:#000000
!important; font-size:13px !important;"><b>Cc:</b>
<a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:Kea-users@lists.isc.org"><Kea-users@lists.isc.org></a></div>
<div style="font-family:Tahoma !important; color:#000000
!important; font-size:13px !important;"><b>Subject:</b>
[Kea-users] How to get kea to reassign same IP after an
explicit release (client reboot) if it has not been reused</div>
<br>
</div>
</div>
<blockquote type="cite"
cite="mid:CAMEa=fk3FV8d2fXR5B8-A795RGxytMUf_SwpUbesXfALaJy4cQ@mail.gmail.com"
style="border:none !important; margin-left:0px !important;
margin-right:0px !important; margin-top:0px !important;
padding-left:0px !important; padding-right:0px !important">
<pre class="moz-quote-pre" wrap="">Hi Nathan,
I experienced the same strange behaviour. For me, the only solution
was to prohibit "release" packets at all. In database I inserted:
table: dhcp4_client_class
{"id":"3","name":"DROP","test":"pkt4.msgtype==7","next_server":null,"server_hostname":null,"boot_file_name":null,"only_if_required":"0","valid_lifetime":null,"min_valid_lifetime":null,"max_valid_lifetime":null,"depend_on_known_directly":"0","follow_class_name":null,"modification_ts":"2022-05-17
20:18:42","user_context":null}
table: dhcp6_client_class
{"id":"2","name":"DROP","test":"pkt6.msgtype==8","only_if_required":"0","valid_lifetime":null,"min_valid_lifetime":null,"max_valid_lifetime":null,"depend_on_known_directly":"0","follow_class_name":null,"modification_ts":"2022-05-17
20:16:00","preferred_lifetime":null,"min_preferred_lifetime":null,"max_preferred_lifetime":null,"user_context":null}
Blažej
so 8. 10. 2022 o 5:45 Nathan Neulinger <a class="moz-txt-link-rfc2396E" href="mailto:nneul@neulinger.org"><nneul@neulinger.org></a> napísal(a):
</pre>
<blockquote type="cite" style="border:none !important;
margin-left:0px !important; margin-right:0px !important;
margin-top:0px !important; padding-left:0px !important;
padding-right:0px !important">
<pre class="moz-quote-pre" wrap="">From reading docs, it sure seems like these settings should result in the desired 'affinity' behavior, but it seems like maybe that is only working when it's an expiration, and not a 'release'?
"expired-leases-processing": {
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"reclaim-timer-wait-time": 10,
"unwarned-reclaim-cycles": 5
},
________________________________
From: Nathan Neulinger [<a class="moz-txt-link-freetext" href="mailto:nneul@neulinger.org">mailto:nneul@neulinger.org</a>]
Sent: Friday, October 7, 2022 at 10:41 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:Kea-users@lists.isc.org"><Kea-users@lists.isc.org></a>
Subject: How to get kea to reassign same IP after an explicit release (client reboot) if it has not been reused
Scenario:
Lightly used subnet, reasonably sized pool of addresses, served with an HA pair of Kea v2.2
Client issues a RELEASE as part of reboot process
Testing with v4 only at the moment
The client appears get a new IP from the pool every time it reboots. It does this even when no other leases have been granted to or even requested by other devices in the mean time.
While this is certainly "valid" behavior - a client can't _expect_ to get the same IP, especially if network is busy/small pool/etc. -- it's not particularly user friendly. It's also not at all what users are used to on a network that was previously using an ISC DHCPd pair.
Is there any way to get Kea to hand out the same IP for a recently known client identifier if it has not already been given to another client? i.e. prioritize assignment of LRU priority on addresses in the pool unless it was the last client to be given a particular lease?
Ideal would be if the above could be time limited. Something like a "hold time" on a release - where it stays 'assigned but claimable if necessary' to a given client for some defined number of minutes after it is released.
Reservations are not what I'm looking for, we already have those, this is specifically in regards to 'purely dynamic pool' handling.
-- Nathan
------------------------------------------------------------
Nathan Neulinger <a class="moz-txt-link-abbreviated" href="mailto:nneul@neulinger.org">nneul@neulinger.org</a>
Neulinger Consulting (573) 612-1412
--
------------------------------------------------------------
Nathan Neulinger <a class="moz-txt-link-abbreviated" href="mailto:nneul@neulinger.org">nneul@neulinger.org</a>
Neulinger Consulting (573) 612-1412
--
ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.
To unsubscribe visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>.
Kea-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kea-users@lists.isc.org">Kea-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/kea-users">https://lists.isc.org/mailman/listinfo/kea-users</a>
</pre>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="120">--
------------------------------------------------------------
Nathan Neulinger <a class="moz-txt-link-abbreviated" href="mailto:nneul@neulinger.org">nneul@neulinger.org</a>
Neulinger Consulting (573) 612-1412</pre>
</body>
</html>