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 Neulinger [email protected]
> Neulinger Consulting (573) 612-1412
>
> --
> ------------------------------------------------------------
> Nathan Neulinger [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
--
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
