DHCP code in 2.0.4+

[Karl Auer]

On Sun, 2009-06-07 at 15:18 +0100, Alexander Clouter wrote:
> 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.

Where you store the state is irrelevant, though it's easier to manage
and more scalable if it's in a database. It's what you do with the state
that is important.

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

I think we are talking quite different kinds of load balancing. I'm
talking about balancing the leases between the two participants in a
failover relationship, you are talking about packet-level
load-balancing. My bad.

> The takeover and recovery is just something that helps people not need a 
> load-balancer and spit out packets to the broadcast address of the VLAN 
> both the DHCP servers sit in.

What? Either you are talking about real DHCP failover or you are not. If
both the DHCP servers in a failover relationship are in the same VLAN,
you have a problem right there. Takeover and recovery are the entire
point of having failover at all.

> We personally use Cisco's IOS (which is pretty naff, but just about 
> usable[1]), but you could use a Linux based HA system.

I think we are talking about different things here. But I'd still like
to see whatever docs there may be on how freeradius does failover.

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/349e493e/attachment.pgp>