I'm not sure this actually answers your questions but Kea can handle host reservation conflicts on its own. See section 8.3.2 [1] for details of how that works. I think in general there are a few approaches to this issue:
1. Don't assign a reserved IP address from the pool. This only works if your pool is smaller then the entire subnet being served and the IP addresses outside the pool are not already in use. 2. Reserve a known unused IP address and then wait to ensure that the IP address was not picked up by another system sometime between discovery of the unused address and defining the reservation *BEFORE* calling the DHCPDISCOVER from the intended host. This way you are guaranteed that the reserved IP address will not be used by another system. 3. Same as #2, but reserve any IP address and just wait for the DHCP server to deny the renewal of the soon-to-be-reserved IP address. In the case where you cannot wait for the host reservation then just define reservation and let Kea resolve the conflict as described in section 8.3.2 [1] of the documentation. This, of course, will mean that your new host will get a temporary address until the reserved address is available. [1] https://kea.readthedocs.io/en/kea-1.6.1/arm/dhcp4-srv.html#conflicts-in-dhcpv4-reservations On 5/6/20 1:28 PM, Chad Catlett wrote: > Hello, > > We are using the subscriber hooks, currently running 1.6.1. > > We currently have a subnet with 1000+ leases and we have a need to create > host reservations for some new devices that will be on the subnet. > > I am attempting to figure out the most sound way of finding available IPs. We > can get a list of leases for the subnet via the API, and then find a free IP. > Our concern is that this subnet sees a ton of dhcp traffic and there is the > risk of us finding a free IP and it being given out as a lease before we have > a chance to submit an API request to add the lease. > > I was hoping there was some kind of argument that we could pass in via the > API that causes it to auto assign an available IP, but that doesn't seem to > be possible. > > How are others solving this in a way that creates zero to very tiny risk of > conflicts. > > Thanks, > > Chad > > -- > Chad Catlett > c...@catlett.info > _______________________________________________ > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users -- Thanks, Joshua Schaeffer
_______________________________________________ Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
