DHCPv6 failover protocol?

David W. Hankins David_Hankins at isc.org
Sun Mar 8 16:27:42 UTC 2009


On Sat, Mar 07, 2009 at 12:10:04PM -0500, John Jason Brzozowski wrote:
> deployment leveraging DHCPv6.  If some form of load balancing is not in 
> place then one server carries more of the burden that others in a cluster 
> of DHCPv6 servers.

I didn't mean "no load balancing," I mean "no explicit new algorithm
or load balancing feature is required."

Meaning, we can do it already.

I think you can write a small 1-5 line function that delivers a
different preference option to the client depending on which server
is emitting the option.  Each server would emit a different preference
for different clients, and you'd rig the algorithm so that there was
population balance.  (Writing this in dhcpd.conf language may be a bit
hard right now, but possible I think, and if we knew more about how
this works we could provide some assist functions.)

The client selects the highest preference, and so you load balance on
a per-client basis by having per-client preferences.

Of course clients that are Renewing won't pay attention to
preferences, so if you needed to be able to rebalance after a series
of outages, you would have to get the client to rebind.  So you might
just ignore Renews from clients for whom the server isn't the highest
preference, catching them on the Rebind.  Can't do this right now, but
it is also trivial (a 'deny booting;' alike in a dhcpd.conf executable
statement, probably combined with the Preference value selector but
depending upon the client packet being a Renew).

But RFC 3315 is very mealy-mouthed on the subject of how a client
selects an Advertise to Request.  It permits a client to ignore the
preference if there is an Advertise "it likes better," but doesn't
go into details.  So this is why I am not "sure" we need an explicit
load balancing algorithm for DHCPv6 - it depends upon client
implementors to see wisdom RFC 3315 doesn't currently encode (they
might just give up at the current language and ignore the preference
option).

So it "waits to be seen" in my mind.

> This creates some notion of hierarchy amongst servers and this also does 
> not address the issue of what happens when one or more servers go down.  

One other note is that I still have a very specific inclination to
what the word 'failover' means, since the current DHCPv4 software has
something we call 'failover.'

'Clustering', on the other hand, is a different thing in my mind, with
slightly different design constraints and requirements (which vastly
change the implementation), and I think we have always needed a
clustering solution independent of DHCPv4's failover...we still will
with DHCPv6.

Clustering, actually, is how I would like to bring multi-core support
to ISC DHCP.

-- 
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/20090308/f8d1b505/attachment.bin>


More information about the dhcp-users mailing list