Peer holds all free leases on two subnets

[Patrick Trapp]

Yeah, I see that opinion expressed a lot.

I did a lot more reading since posting that. The balancing report, if that's what it is called, showed over a thousand addresses available in the pool for each of the hosts. I was pretty sure it wasn't out of addresses and that seemed to confirm it.

I did get it working, but I'm still perplexed. More background was necessary - I use option 82 information to determine what pool the device address should come from because we assign addresses from different pools according to the device making the request. As part of that, there was an allow statement in the pool definition. In this particular include file, I am actually only serving addresses to a single type of device. I removed the allow statement and addresses started being assigned once again.

The puzzlement comes from the fact that I literally copied the configuration from one include file into a new include file. In the original file, it worked. In the new file, it failed. I even restored the original file to the configuration and restarted the service - still didn't work.

Thanks for the reply.

________________________________
From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on behalf of Bob Harold [rharolde at umich.edu]
Sent: Monday, October 12, 2015 3:50 PM
To: Users of ISC DHCP
Subject: Re: Peer holds all free leases on two subnets


On Mon, Oct 12, 2015 at 7:38 AM, Patrick Trapp <ptrapp at nex-tech.com<mailto:ptrapp at nex-tech.com>> wrote:
OK, first of all, I'm sure I caused this one. (Usually, I don't realize it so quickly, so that's progress, I guess.) I just don't know why it's happening.

Short form: I attempted to copy an include file to a new name to match our standard naming convention. Since that point, the include in question fails to work, returning "peer holds all free leases" from both servers of the failover pair.

Long form: Our dhcp 'domain' includes a fairly high number of subnets spread over a wide geographic area, so to make it relatively manageable, we use a lot of include files - in most cases, each shared network has its own include to make it easier for me to locate them and not have a huge conf file to wade through. Some larger communities have multiple shared networks and I combine them into a single include.

Last week, I was tasked with creating new dhcp scopes for a town with an existing network. To be consistent with my other configurations, this requires a new include file. Creating this file was no problem and (as far as I know) all is fine - testing may not have started on it, though.

However, in the process of looking over the status quo to create that new file, I realized that the include file for the existing network didn't meet our naming standards and sought to remedy that fact. I didn't want to change the existing file in case I needed to roll back, so I copied it to a new include file and went into the dhcpd.conf where I added the new file and commented out the old one. Ever since that time, the devices that should be served by the new include are triggering "peer holds all free leases" errors on both servers. All other pools are operating normally, as far as I can tell (the log is so full of "peer holds" messages that is it hard to be certain). We have rolled back the changes to the prior configuration without helping the situation. We have restarted the service a number of times and rebooted both dhcp servers completely once. I have stopped the secondary server and put the primary server in partner-down in hopes that it would take over the entire pool, but that doesn't appear to have made much difference.

I don't know why this caused this issue and more importantly, I don't know how to recover. Ideas, suggestions, and criticism welcome. Thanks!


It has been my experience that "peer holds all free leases" really means "I cannot give you a lease for some reason".  It could be that the range is full and the few remaining leases are held by the peer, but it could also mean that the client did not match the "allow class" or some other restriction on the range.  The message is misleading in my opinion.

--
Bob Harold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20151012/7d12cf8a/attachment.html>