DHCP code in 2.0.4+

Karl Auer kauer at biplane.com.au
Sun Jun 7 18:57:26 CEST 2009


On Sun, 2009-06-07 at 17:20 +0100, Arran Cudbard-Bell wrote:
> For purposes of resilience there is absolutely no requirement for DHCP
> servers to communicate with each other directly. They just need a common
> source of knowledge about DHCP lease allocation.

OK - but lets not talk about "DHCP failover" then, which has very
specific meaning in a DHCP context. "Resilience" is a good term.

You are basically talking about making sure the DHCP service stays up by
using multiple servers accessing a common data source, and then making
sure the data source stays available. Fair enough - but it isn't
failover.

And of course it means you can make the actual DHCP servers much simpler
- for a start they don't have to implement failover :-) Probably a very
good thing because as I believe I may have mentioned, it isn't trivail
to do.

> All this goes away. You run multiple servers in active/active mode;
> there is no takeover or recovery. All DHCP servers act as one, they all
> have an identical view of the state of the various leases.

Yes indeed. However the supply of that resilient common view requires
quite a bit of cooperating hardware and software. You have made the DHCP
side of things much easier, but the back end is now more complex. I'm
not sure you get to call a resilient, high-availability clustered
database "trivial" either :-)

One down side is that you need all your DHCP servers to be the same; you
lose interoperability. That may or may not be a problem.

Another downside might be DHCP response time - how fast can you get
addresses out when obtaining one involves a call into the database? Have
you tested that side of things yet? (I'm not sure whether you have DHCP
servers actually working this way or are talking about how they could or
should work).

> >  in the case where
> > a server drops out, is not reachable by its peer or is deliberately
> > taken offline. Not to mention the possibility of having several servers
> > participating in various failover relationships.
> >
> >   
> *sigh* don't overcomplicate it.

Life complicates things. You have to deal with it. However, with a
common data source driving your DHCP, you also don't have to worry about
creating meshes of DHCP failover relationships, because failover has
disappeared.

It's one of the great things about DHCPv6, by the way - no more
failover!

> One of the good points you made was about load balancing; Any idea how
> this is done in existing DHCP server solutions?

Er - packet or DHCP-level balancing? We have never needed packet level
load balancing; the servers we use have never come remotely close to
needing it. I suppose a bigger network might need it, though in that
case I'd be wanting a better DHCP server distribution rather than load
balancing hardware. For DHCP balancing we've always just distributed the
addresses 50/50.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090608/3d8749e3/attachment.pgp>


More information about the Freeradius-Users mailing list