expired lease problem

[Bill Shirley]

Do you really need the allow unknown-clients in your pool definition?
If you define any device with a host statement then it won't be eligible
for the only pool in the 172.210.140.0 subnet.

As I understand it, DHCP will use all the available leases before it will
recycle any for a DHCPDISCOVER.

How does your DHCP know which subnet to use for a request?  Do you
have host or class statements?

Bill


On 11/15/2017 9:49 AM, project722 wrote:
> shared-network "temp" {
>         subnet 172.210.140.0 netmask 255.255.252.0 {
>                 option domain-name "example.net <http://example.net>";
>                 option routers 172.210.140.1;
>                 ## Define the DHCP pool and access list for this pool.
>                 pool {
>                         allow unknown-clients;
>                         failover peer "dhcp-failover";
>                         range 172.210.140.2 172.210.140.255;
>                         range 172.210.141.1 172.210.141.255;
>                         range 172.210.142.1 172.210.142.255;
>                         range 172.210.143.1 172.210.143.254;
>                 }
>         }
>         subnet 172.210.144.0 netmask 255.255.252.0 {
>                 option routers 172.210.144.1;
>         }
>  }
>
> I can't post log entries as we have expanded the pool to patch the issue, so currently there are no errors. However, this pool 
> only shows 74% utilization. And all it takes is a few more turn-ups to cause this problem.
>
>
>       Subnet 172.210.140.0/22 <http://172.210.140.0/22>
> --------------------------------------------------
>
>
>      Monitoring:      ON
>      Warning limit:   80%
>      Critical limit:  90%
>      Active leases:   762/1018 (74.9%)
>
> As I've mentioned before, the only thing that stands out to me in dhcpd.leases is the fact that we have a couple hundred of 
> "expired" leases, which could and should be used, even though these are actually being held in the expectation that the 
> previous client will return. (At least, that is my understanding)
>
> But, what is expected behavior here? For example, if we have 500 leases, 250 of them have a binding state of active and the 
> other 250 have expired if a new client comes along DHCP should free up one of the expired ones, correct?
>
>
>
> On Tue, Nov 14, 2017 at 3:24 PM, Bill Shirley <bill at c3po.polymerindustries.biz <mailto:bill at c3po.polymerindustries.biz>> wrote:
>
>     Post your pool definition and log file excerpts.
>
>     Bill
>
>
>     On 11/14/2017 12:07 PM, project722 wrote:
>>     We had an unusual problem last night where the server was not able to give out any more leases from a specific pool. The
>>     server logs showed " no more free leases". This is a RHEL 6.7 server running dhcp 4.1.1.
>>
>>     We have scripts that run which look for active leases. In the pool in question we had over 200 available leases but the
>>     server was unable to provide them to a client. I dug around in dhcpd.leases and found what I think is the problem. I
>>     found a ton of leases in the "expired" state with an end date of 11/6. Which, If I am correct, will never move into it
>>     next binding state of free so it can be used because its a date in the past.
>>
>>     Here is an example of one:
>>
>>     lease 172.210.141.159 {
>>       starts 2 2017/11/07 11:40:37;
>>       ends 2 2017/11/07 12:10:37;
>>       tstp 2 2017/11/14 11:55:37;
>>       cltt 2 2017/11/07 11:40:37;
>>       binding state expired;
>>       next binding state free;
>>
>>     Am I correct here? If so, what causes this problem and how can I fix it? I have restarted dhcpd, but that does not help.
>>     If I were to edit /var/lib/dhcp/dhcpd.leases manually and remove these entries what are some things I should take into
>>     consideration?
>>
>>
>>     _______________________________________________
>>     dhcp-users mailing list
>>     dhcp-users at lists.isc.org <mailto:dhcp-users at lists.isc.org>
>>     https://lists.isc.org/mailman/listinfo/dhcp-users <https://lists.isc.org/mailman/listinfo/dhcp-users>
>
>
>     _______________________________________________
>     dhcp-users mailing list
>     dhcp-users at lists.isc.org <mailto:dhcp-users at lists.isc.org>
>     https://lists.isc.org/mailman/listinfo/dhcp-users <https://lists.isc.org/mailman/listinfo/dhcp-users>
>
>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20171115/92ead7c5/attachment-0001.html>