DHCP code in 2.0.4+

[Arran Cudbard-Bell]

Alexander Clouter wrote:
> Karl Auer <kauer at biplane.com.au> 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.
>>
>>     
> The state lives in the database.  ISC's DHCP has it's own 'database' 
> which is just a flat text file...FreeRADIUS just puts everything in SQL.
>
> I think Alan's great example is shutdown one of your DHCP servers, scrub 
> the dhcpd.leases file and fire it up again and watch what happens.  Also 
> if I see one more damn "peer owns all the leases" message in my logs, 
> I'm likely to cause someone harm :)
>
>   
>> And that is quite apart from the carefully timed state management that 
>> must occur during takeover or recovery 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.
>>
>>     
> This is all solved by *load-balancing*.  If your load-balancer cannot 
> detect that a DHCP/RADIUS server is dead then you need to get a better 
> load-balancer.
>   
There are also very intelligent ways to achieve load balancing between
peers.

One option is to calculate a skew time based on the difference between
the leases allocated by the local server and the maximum number of
leases allocated by a peer in the cluster.

When a discover packet is received, the peer with the lowest number of
leases allocated, responds immediately. The others wait skew_time to
see  if a DHCP Offer is broadcast by one of the other peers. If the
local server receives no such offer after skew_time, it sends a DHCP offer.

Problems with network latency... and it might not work as the code is
currently... but still not incredibly hard to implement.

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/4408d510/attachment.pgp>