[Kea-users] Lease affinity of released leases

Wed Nov 10 16:34:00 UTC 2021

Hi Johannes,

I encourage you to open an issue at https://gitlab.isc.org/isc-projects/kea <https://gitlab.isc.org/isc-projects/kea> to request a feature to enable your use case. I seem to remember we once discussed some sort of ‘automatically create a reservation’ feature but I didn’t really understand the use case for it. It really helps when users describe how they expect the feature to work.  For example, how do you know what to put in the HR to identify the client if you don’t have any identifier for the client??

I don’t know what to do about affinity after a release - I think that might be a protocol issue…

Vicky

> On Nov 10, 2021, at 9:14 AM, Johannes Midgren <johannes at midgren.net> wrote:
> 
> Yes, a reservation does solve the basic problem, but not my particular use case. One thing that I like to use KEA for is to automate "onboarding" of new hosts (physical, VMs or containers). To be able to make a reservation I would first have to get hold of the MAC address (or client ID), which is a bit cumbersome, and then the reservation is done outside of the pool range in my setup, which makes the host change IP address. What I'm trying to achieve is that the host name I set and that is forwarded to KEA through the Client FQDN option is registered with my DNS so that I can access the host using the name.
> 
> Den ons 10 nov. 2021 kl 14:52 skrev <egor.grijuc at orange.com <mailto:egor.grijuc at orange.com>>:
> Maybe a host reservation is a solution?
> 
>  
> 
> From: Kea-users <kea-users-bounces at lists.isc.org <mailto:kea-users-bounces at lists.isc.org>> On Behalf Of Johannes Midgren
> Sent: Wednesday, 10 November 2021 15:47
> To: kea-users at lists.isc.org <mailto:kea-users at lists.isc.org>
> Subject: [Kea-users] Lease affinity of released leases
> 
>  
> 
> TLDR: How do I make KEA offer the same IP to a host that is rebooted and that releases its IP address while shutting down?
> 
>  
> 
> I have recently started to use KEA on my home network. I love the fact that I can control its configuration through Ansible and all the possibilities the REST API gives, so I'm very glad that I found the project!
> 
>  
> 
> One thing that I still have not been able to get the way I prefer it though, is to have lease affinity in all cases. That is, I would like for a client to always get the same IP address when it reconnects (as long as it's still available of course). I have read the chapter about Lease Expiration (and Affinity) in the manual and I'm not sure the case I'm looking for is covered. The manual talks about expired leases, but I would like to have affinity also in the case that the lease has been released rather than expired. Using a packet sniffer I can see that clients tend to properly release the DHCP lease when being rebooted and when it gets online again it does a DHCP Discover and is offered a new IP address by the KEA DHCP4 server.
> 
>  
> 
> Does anyone know if KEA is supposed to (or rather can be made to) work the way I intend it to or if lease affinity by design is only supposed to work for expired, thus not released, leases? (Or maybe something is wrong with my setup and this should actually work?)
> 
>  
> 
> The problem I have is that cached DNS entries make hosts unavailable for some time after they are restarted - they are "sought for" by their old IP. I guess I can mitigate the issue by setting a very low TTL in my DNS configuration, but I would prefer to let KEA hold leases for a long time and reuse them instead. Another way would of course be to make reservations for all hosts where this matters, but that prevents the automation that I try to use KEA for.
> 
>  
> 
> I have been playing with the expired-leases-processing configuration for the DHCP4 server, and I currently have this:
> 
>  
> 
>        "expired-leases-processing": { 
>            "flush-reclaimed-timer-wait-time": 300, 
>            "hold-reclaimed-time": 604800, 
>            "max-reclaim-leases": 100, 
>            "max-reclaim-time": 250, 
>            "reclaim-timer-wait-time": 180, 
>            "unwarned-reclaim-cycles": 5 
>        },
> 
> I'm running KEA 1.8 (installed from CloudSmith repos) on CentOS Stream 8. I use the memfile lease-database, have DHCP-DDNS setup and I use the HA hook (with one primary, one standby and one backup host).
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> 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/20211110/2d06f4e1/attachment.htm>