DHCP code in 2.0.4+

[Arran Cudbard-Bell]

Karl Auer wrote:
> On Sun, 2009-06-07 at 14:09 +0100, Arran Cudbard-Bell wrote:
>   
>> Karl Auer wrote:
>>     
>>> DHCP failover and load-balancing are not simple *at all*.
>>>   
>>>       
>> They're trivial once you're storing leases in a transactional database.
>>     
>
> With all due respect, Arran, no, they are not.
>
> Two DHCP servers in a failover relationship must communicate with each
> other, each maintaining information about the state of leases that the
> other has.
>  If they do so via a shared database (which seems to be what
> you are suggesting, apologies if not) then the entire point of failover
> is lost.
Clustered MySQL still has support for transactions.

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. Additionally there is
no need for there to be this active/passive relationship between
servers. RFC 2131 explicitly supports multiple DHCP servers operating on
the same network, it even says that multiple DHCP servers can offer the
same lease (it just makes the process a little less efficient).

The key state change for a lease occurs when a client actually requests
it. Granted this could be a major headache if both DHCP servers had to
maintain local copies of lease information and and synchronise them; but
with a resilient central lease database this problem disappears.
>  And that is quite apart from the carefully timed state
> management that must occur during takeover or recovery
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.
>  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.

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

--

The strength of FreeRADIUS as a DHCP server, is that it ties DHCP
functionality into a very rich policy environment. Servers like the ISC
DHCP server don't integrate well with modern databases or directories,
and their configuration syntax is often very baroque and inflexible.

For sites moving towards policy driven networks, using FreeRADIUS as a
DHCP server allows them to extend what they've already achieved with
RADIUS/802.1X in terms of auto-configuration of the edge network, and
bring it into the client domain.

Arran

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20090607/5dbccbf6/attachment.pgp>