How to debug "Got POOLREQ, answering negatively"?

[David W. Hankins]

On Sun, Apr 19, 2009 at 05:03:40PM +0200, sthaug at nethelp.no wrote:
> This comment still stands. If the "Got POOLREQ" message could say which
> pool(s) it was referring to, it would help quite a bit!

I agree.  The POOLREQ failover message according to the last draft
does not specify which pool the peer is interested in balancing,
however.  So currently there's no way for the server that receives
this message to know which pool to compare to...('pools' are not a
standard failover protocol construct, just leases).

This is also a performance problem, as the server that receives this
message must iterate over /all/ pools at once.

My thinking lately has been for the peer (sending the POOLREQ) to
also provide one of the addresses in the pool it thinks is misbalanced
enough to generate the response.  The receiving server could use the
address to find the pool, and would only balance this one pool in this
case.  We could also lift the restriction that the server only send
one POOLREQ at a time (now you could send 5 for the 5 specific pools
you care about).  It sounds like we could add the peer's
active/free/backup statistics for logging purposes.

I'm also debating if we should take more stringent action on a
negative answer to a POOLREQ.  Something like taking a trip through
potential-conflict, but this worries me.  This could self-heal db
inconsistencies (which has the unfortunate side effect that we'd
probably stop hearing about db inconsistency bugs).

And so long as we're talking, it would be great for there to be
some way other than the hex-printed address in memory of the pool
structure to uniquely name a pool.  :(


For the time being, I think you should be able to check the peer's
logfile, as its balance run entry for the pool in question will
indicate its desire to request rebalance (I think it logs this even
if multiple pools want to send POOLREQ...I think it appends
"requesting pool rebalance!" or something).

-- 
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: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090420/88ef8ed5/attachment.bin>