What causes "balancing pool" messages ?

[David W. Hankins]

On Wed, Jan 09, 2008 at 11:23:29PM -0600, Nomad wrote:
> Jan 9 04:13:23 DHCP1 dhcpd: balancing pool a854600 172.16.81.96/28 total 9
> free 6 backup 3 lts 1 max-own (+/-)1
> Jan 9 04:13:23 DHCP1 dhcpd: balanced pool a854600 172.16.81.96/28 total 9
> free 6 backup 3 lts 1 max-misbal 1

These ocurr on a schedule now in 3.1.0; by default it will happen at
least once an hour, and should happen no faster than 60 seconds.

> For each network segment, I see these messages coming in every minute.  In
> case it matters, here's the failover section of my dhcp servers:

The leases database is more interesting for this than your failover
config (except that you have not set min-balance to override the 60s
default).  The server is trying to estimate when the remote-system's
pools are going to reach the "max lease misbalance" point at the
current estimated rate of change (as measured by the oldest free and
backup leases expiration times).

It only reduces this estimation, but never below min-balance, so in
practical terms it takes the "worst case" pool, the pool that
indicates the most near term potential schedule for reaching
max-misbalance.

At least according to theory, the amount of time inbetween balance
events should rise as the expiration times on your free/backup leases
become more distant memories of the past, and it should dynamically
become more frequent as recent activity makes them more fresh.

If your practice is that leases cycle owners so fast they never get
to become memories of the distant past, you can simply raise the
min-balance percentage as a workaround.  The dhcpd.conf manpage has a
section on min-balance and the other parameters that govern pool
balance maintenance.

> And by the way, what does the "lts" mean in these messages?

"leases to send."  The convention predates me, but if the local system
(logging the line) were to send 'lts' leases to its peer's state, then
the pool would be "evenly balanced."

So the logs you're pasting are showing that the server looked, but
took no action (the lts number before and after did not change).

It is normal for;

lts to be greater than max-misbalance on a "balancing" line.

lts to be greater than zero on a "balancing" line, but less than zero
on a "balanced" line (leases were shifted to the peer according to
their most recent client and the load balancing hash algorithm).

lts to remain precisely the same non-zero value less than or equal to
'max-own' between both log lines.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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