Troubleshooting: no free leases

[Gregory Sloop]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170720/d94f9b09/attachment.html>