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.
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.
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.
-- Nathan
------------------------------------------------------------------------------------------------------------------------
*From:* Blažej Krajňák [mailto:[email protected]]
*Sent:* Saturday, October 8, 2022 at 4:03 AM
*To:* Nathan Neulinger <[email protected]>
*Cc:* [email protected] <[email protected]>
*Subject:* [Kea-users] How to get kea to reassign same IP after an explicit release (client reboot) if it has not been
reused
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<[email protected]> napísal(a):
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 [mailto:[email protected]]
Sent: Friday, October 7, 2022 at 10:41 PM
To:[email protected] <[email protected]>
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 [email protected]
Neulinger Consulting (573) 612-1412
--
------------------------------------------------------------
Nathan [email protected]
Neulinger Consulting (573) 612-1412
--
ISC funds the development of this software with paid support subscriptions.
Contact us athttps://www.isc.org/contact/ for more information.
To unsubscribe visithttps://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
--
------------------------------------------------------------
Nathan [email protected]
Neulinger Consulting (573) 612-1412
--
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
