DHCP code in 2.0.4+

[Alan DeKok]

Arran Cudbard-Bell wrote:
> 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.

  There's a lot of magic that happens behind the scenes with DHCP
servers using the failover protocol.  They maintain a *very* complex
state machine where each lease has a large number of states and
parameters associated with it.

  My time spent in the area convinced me that the complexity is
unnecessary, poorly understood by everyone, and fragile.

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

  Karl is talking about the servers exchanging the state of the lease
during the internal state changes that they undergo as they allocate the
lease.  Most DHCP people think it's necessary.  I agree it's necessary
in certain edge conditions.  But also that the *normal* conditions don't
need it.  And it's so fragile that it causes more problems than it solves.

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

  Badly.  MAC addresses are hashed (via a bad hash), and then mapped to
unallocated IP's in a pool.  If that IP is "owned" by the other server
in a failover relationship, even *more* complexity results.  The server
has to ask the other server for more leases.  If it's slow (or down),
you get the dreaded "peer holds all leases" message.

  EVEN WHEN THERE ARE TONS OF FREE LEASES.

  Bizarre...  I can't understand why it would be done that way, when
other ways are simpler, more robust, and achieve the same goal.

  But that brings us back to the DHCP world view:  The problem is
defined to be "implement the failover protocol", and the solution is
"the failover protocol".  IMHO, admins don't care about it.  They care
about having a robust DHCP infrastructure with load-balancing and HA.

  That's relatively easy.  And it's surprisingly easy to the people used
to working with existing DHCP systems.

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

  Exactly.

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

  That's the goal.

  Alan DeKok.