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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
