Troubleshooting: no free leases

Glenn Satchell glenn.satchell at uniq.com.au
Fri Jul 21 07:52:00 UTC 2017


Hi

Typically "no free leases" means that it didn't match any classes, so
failed to get an address. There's no history because until it gets to the
end it doesn't know that it has failed. You probably don't have any full
pools.

My guess is that looking at all the allow and deny settings you have in
each pool in dhcpd.conf. This is not necessary, as if you allow one or
more classes, everything else is denied. This is an area where various
optimisations have taken place and could cause differences between
versions.

So I would suggest removing all the deny lines there, just leave the allow
ones you want.

regards,
-glenn

On Fri, July 21, 2017 2:26 pm, Gregory Sloop wrote:
>
>
>
> Hi,
> fwiw, I just upgraded isc-dhcp-server, I'm now running: 4.3.1-6+deb8u2
> (things were working fine before that point, I'm not sure offhand what
> version I was running previously,  unfortunately). And I got the problem
> below. I've since upgraded to 4.3.5-3 (Debian stretch) without any
> improvement.
>
> And I hit "no free leases".
> I'm hoping someone could help me figure out what's going wrong / how to
> fix it.
>
> This is most of my dhcpd.conf [1] file.
>
> The client I'm trying to get a lease for is a modern.ie Windows10 VM [2]
> running in VirtualBox 5.1.24 on macOS Sierra w/ guest additions Bridging
> an Thunderbolt Ethernet Adapter [MAC address: 08:00:27:d0:ad:b7]
> WireShark shows the windows 10 system sends:
>   MSEDGEWIN10<.MSFT 5.07
> WireShark reports it as:
>   Client FQDN: MSEDGEWIN10
>   vendor-class-data: MSFT 5.0
> ... which should match my "win" class.
>
> None of my pool ranges appear "full" [3].
>
> The class match is not logged.
>
> For comparison, here's background logging [4], and what I get when I
> troubleshoot the Windows 10 network [5].
>
> pool 10.4.6.1 .. 10.4.6.254 has allow unknown-clients, which is where it
> would go if it wasn't matched.
>
> One basic question I have is: How do i tell if a pool is "full"?
>
> It would be very helpful to me for debugging if I could get
> isc-dhcp-server to "explain" how it decided that it had no more space.
>
> From my naive perspective none of my pools are full, but I'd rather be
> able to ask isc-dhcp-server its opinion.
>
> I also tried stopping isc-dhcp-server
>
>
> There's no configuration for a failover pair, and the word "failover"
> isn't present in my config file.
>
> I read: release notes [6] -- which shows that the logging was introduced
> in 3.0rc12
>
> I skimmed through: KB looking for "no free leases" [7] and the kb articles
> all seem to be about performance or failover.
>
> Thanks
>
>
> A few quick thoughts, and perhaps some additional data from you.
> IIRC no free leases can and will occur if there's a host statement [that
> has an assigned ip] that matches your client which isn't getting a lease,
> but it's coming from a network that doesn't match the ip in the host
> statement.
> [ie: the host statement assigns 10.0.0.1, but the request is coming from a
> 10.0.1.0/24 network.]
> I suspect matches that don't work out like you thought they would could
> produce similar "odd" results.
>
> But [I think] this should show in the dhcpd logs. [again, IIRC]
> (Increasing debug/verbosity might help too.)
> Are there any relevant logs, and if so, what are they. [I actually suspect
> you'll see the problem if you find the logs that apply to these
> transactions.]
> To tell if a pool is full, I believe you have to look at dhcpd.leases and
> see what's leased. There are some perl [and other] scripts that will do
> that for you, but I don't recall a way to do that automagically with the
> standard dhcpd tools.
>
> HTH
> -Greg
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users




More information about the dhcp-users mailing list