'MAC affinity' doing the exact opposite, leading to 'pool churn'?

[David W. Hankins]

On Mon, Sep 24, 2007 at 04:55:38PM +0200, Bart Van den Broeck wrote:
> I've observed a case in which the exact same client (a GNU/Linux machine) is
> getting a different IP from the same peer (primary) in a failover pair upon
> each (re)boot.  My guess is that, since the previous lease had already expired,
> that lease was allocated to the *OTHER* (secondary) peer after expiry, although
> it was given to the client by the primary peer before.  Because the primary
> needs to answer the request due to load balancing, it can't but give the
> client a new IP.  It seems a case of 'MAC affinity' doing exactly the opposite
> of what can be expected.  Or am I misinterpreting this?

This client hashes to the primary (or I assume s1 is primary) - mac
affinity assigns leases to the secondary.  That is, 'free' is the
default case, the whole affinity thing is an extra step that moves
free leases to backup if they reverse-hash.  So it would be unusual,
but I suppose it's not impossible as far as bugs go.

However, I would tend to suspect pool balance to be the culprit here,
since your primary appears to be pushing the upper limit on what it's
allowed to own for the purposes of affinity (20 for this pool).  This
suggests that the primary is having to send some number of the leases
it would like to keep for itself - but must give over in order to keep
the pool reasonably well balanced.

If that were the case, however, I'd also expect to see more 'pool' log
lines, since that's the only way such leases would get moved over to
the secondary (and then only if the primary's "lts" calculates out to
greater than max-own).  This kind of balance is not effected on the
'client affinity' steps.


So whatever the case, this looks pretty odd.


You can apply this to add some debug messages to see if affinity is
giving these leases away (incorrectly):

Index: failover.c
===================================================================
RCS file: /proj/cvs/prod/DHCP/server/failover.c,v
retrieving revision 1.63.56.10
diff -u -r1.63.56.10 failover.c
--- failover.c	17 Sep 2007 17:20:25 -0000	1.63.56.10
+++ failover.c	24 Sep 2007 17:17:41 -0000
@@ -5007,6 +5007,10 @@
 		    !write_lease(lease))
 			log_error("can't commit lease %s for mac addr "
 				  "affinity", piaddr(lease->ip_addr));
+		else
+			log_debug("failover: lease %s given to secondary "
+				  "for client affinity on update",
+				  piaddr(lease->ip_addr));
 
 		dhcp_failover_send_updates(state);
 	}
@@ -5183,6 +5187,10 @@
 		    !write_lease(lease))
 			log_error("can't commit lease %s for "
 				  "client affinity", piaddr(lease->ip_addr));
+		else
+			log_debug("failover: lease %s given to secondary "
+				  "for client affinity on ack",
+				  piaddr(lease->ip_addr));
 
 		if (state->me.state == normal)
 			commit_leases();

-- 
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