Solving POOLREQ... how?

David W. Hankins dhankins at isc.org
Tue Jul 14 18:08:56 UTC 2009


On Mon, Jul 13, 2009 at 02:22:16PM -0400, Jeffrey Collyer wrote:
> Then I added a set of about 20 networks to the config on each machine and 
> upon restart I start seeing this on the primary :
>
> Jul 13 14:07:39 primary dhcpd: peer fopeer: Got POOLREQ, answering 
> negatively!  Peer may be out of leases or database inconsistent.

As you're running 4.1, your peer will send a POOLREQ if any single
pool under its command is misbalanced in the peer's favor by more
than double the "drift" allowance (to "wake it up" and get some of
those leases sent their way).  That peer will check all pools and
respond with a count of how many leases it was able to send over.

Normally, POOLREQ is not required, and is never normal, because
servers follow a schedule to rebalance pools before misbalance starts
to become an issue.

This can be a short-lived, temporary condition, before balances happen,
but that's rare.

When it's persistent, it can be that the config files are inconsistent
(or that the primary has not been restarted on the new config).

Or it can be that the lease database has gotten inconsistent for some
pool, the only solution for that is to 'fault' one lease database
(kill/rm/touch/start) so that the server can load a fresh copy from
the peer, wait MCLT, and rejoin service again.

If you look at the pool 'balanced' log lines, it may shed more light
on what pools are affected.  For example, if the new pools do not
appear in the primary's log, then they are not in configuration.  If
the secondary doesn't have the pool in configuration, but still has a
misbalanced pool, it may be a typo in the secondary's config...

> pool response: 1 leases

Since the POOLREQ-receiving server will traverse all pools on every
POOLREQ, it is possible that it may find a lease in some pool to grant
the peer.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090714/8482c5a2/attachment.bin>


More information about the dhcp-users mailing list