DHCP failover lease balancing with nearly saturated pools

[Jack Kielsmeier]

I apologize for not including the version number I am running.

I'm running 3.1.0 on Sun Solaris (Sparc). More comments inserted inline
below.
-- 
Jack Kielsmeier <jackkiel at netins.net>


> On Wed, Jan 28, 2009 at 01:48:15PM -0600, Jack Kielsmeier wrote:
> > Currently, when the pools become nearly 100% saturated, the primary
> > server throws out 'peer holds all free leases' errors. This is correct
> > because the peer holds the final lease. Since I'm shipping all traffic
> > to the primary server, that last lease will never be given out.
> 
> I don't know as of what version, but if the servers agree on the
> lease states (no db synch. problems), then the secondary should know
> that there are zero free leases and will over-ride the LBA
> algorithm.

The way in which we have out network laid out, the secondary doesn't see
DHCP traffic (except of course the load balancing traffic occurring on
port 520).

These two servers are separated by about 60 miles behind redundant LBS
switches. The LBS sends traffic to only the primary server, unless it
sees it down, then it ships traffic to the secondary. The LBS ships off
unicast DHCP traffic to our DHCP servers.

The primary server hands out leases, and the pools on busy subnets are
balanced every 5 minutes or so. When there is only one lease left, the
secondary won't balance that lease over to the primary.

I figured this was by design, as the load balanced design of dhcp
assumes both servers will see the same traffic. If this was the case in
my situation, I'd assume the secondary would hand out the lease knowing
it has the only valid one left for the pool, and it was in control of it.
But in my case, the secondary never sees the request so it doesn't know
to hand it out. The only way the lease could be handed out is if the
primary server went down and DHCP traffic started hitting the secondary.

Of course if the non-used lease were balanced over to the primary before
the request for the lease came in, then things would work well and all
leases would then be used.

I hope this explains my situation in better detail.

> 
> So the version you're running might be an issue.
> 
> The only place I'm not sure is if you've got a series of pools in a
> given shared network, and some of them have ACL's applied that don't
> match the client.
> 
> The other thing is that the peer should offer the lease if the client
> has been (re)trying for more than 'load balance max secs (n);'.
> Note that this is advertised by the client (in the BOOTP header 'secs'
> field), so the servers don't have a lot of say about it, but most
> clients put something useful there.
> 
> -- 
> 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