DHCPv6 failover protocol?

[David W. Hankins]

On Sun, Mar 08, 2009 at 12:43:02PM -0400, John Jason Brzozowski wrote:
> [jjmb] I would willing to collaborate here.

I would start here (e.g. for 4 servers) as a routine for between 2 and
255 servers, to see how well it works (or doesn't);

server A;
	option dhcp6.preference = extract-int(suffix(option dhcp6.client-id, 4), 32) % 4;

server B;
	option dhcp6.preference = (extract-int(suffix(option dhcp6.client-id, 4), 32) + 1) % 4;

server C;
	option dhcp6.preference = (extract-int(suffix(option dhcp6.client-id, 4), 32) + 2) % 4;

server D;
	option dhcp6.preference = (extract-int(suffix(option dhcp6.client-id, 4), 32) + 3) % 4;

Note the last 4 octets and 32-bit wide integer are superfluous on
'%4' (you may just as well use the last octet of DUID and use an 8-bit
extract-int), because all bits above the last octet are congruent to
zero % 4.  But this isn't the case for all numbers of servers, so I
include it for completeness of example.

If you want a broader 'spread' of preference values, you can multiply
these values upwards (multiply by 85 and you get 0, 85, 170, 255).

If you had 2 pairs of servers in geographically distant locations,
you might further adjust the algorithm by using %2+2 on the 'near'
systems, and %2 on the 'remote' systems before multiplying up.  This
nets the same spread but splits the near and far systems in bands.

Anyway...

Everything from the 'extract-int' up to the '%' are candidates for
improving dhcpd.conf syntax (providing some kind of mixer, checksum,
or hash tools).

The extract-int's first argument - the field over which to run the
balancing algorithm - is open to question, and probably would always
stay configurable (the 'xid' field is seductive for fixed-address
deployments).

> [jjmb] If the original server is down the client will continue to renew 
> until rebind.  If the original server has yet to return the client will 
> interact with other available servers.  I think this is what you are 
> saying, if so we agree.

In addition, a server that isn't offering the best preference can
pretend to be down.  It might only do this on certain percentages of
Renewing clients, or during certain time slots (midnight to 6am).  The
Renew times out, the client eventually Rebinds, and if the better
server is back up, they get rebalanced to it based on Preference.  If
the server is not back up, they get the best backup server (which may
be the same one again).

One of the common things we receive complaints about in DHCPv4
failover is that after 'healing' the system, clients do not get
rebalanced between the servers.

Without a rebalance feature (or some expectation of client system
attrition, which is what Failover hopes for), an n+1 system like this
could march all clients upon the one briefly-lone-surviving-server.

If this becomes a common use case, we could probably justify adding
some mechanism to direct a client to skip Renew and go straight for
Rebind.

-- 
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/20090310/1d57fa27/attachment.bin>