DHCP code in 2.0.4+

[Karl Auer]

On Mon, 2009-06-08 at 14:57 +0100, Arran Cudbard-Bell wrote:
> On 7/6/09 17:57, Karl Auer wrote:
> > OK - but lets not talk about "DHCP failover" then, which has very
> > specific meaning in a DHCP context. "Resilience" is a good term.
> 
> Karl; It has a very specific meaning in an ISC DHCP context.

It's not a good sign that we bicker about terminology. Suffice it to say
that "DHCP failover" is not ISC specific, it is implemented by several
DHCP servers and has an (admittedly draft) standard behind it, namely
draft-ietf-dhc-failover-xx.txt. Might be an RFC by now.

>  A clustered system could replicate fail-over behavior, but really
> there'd be little advantage in it doing so.

It could produce a resilient DHCP service. "Little advantage" is putting
it very mildly; bending a clustered system to do failover as per the
standard would be completely pointless. It could not replicate failover
as defined in the draft without doing things like listening on the
failover ports and doing direct server-to-server comms. You'd have to be
desperate for interoperability.

> There is no reason why this behavior couldn't be replicated on a
> request by request basis in a clustered environment. You just need to
> record the fact that a server has made an offer, as well as 
> recording the fact that a lease has been made for an IP address.

Again you are not talking about DHCP failover as defined in the standard
and implemented in much DHCP software. I think it is really important to
distinguish between what you are talking about - which is a Good Thing!
- and actual DHCP failover.  It confuses the issue otherwise.

> configurations and scalability. The actual code base is maintained by
> people who know far more about the concepts behind synchronous
> replication of data than the people maintaining the ISC code or the 
> other DHCP server implementations.

I would be cautious about dumping on the skill levels of others. There
are a great number of variables in these matters, and by no means all of
them are technical. One of the benefits of ISC DHCP, for example, is
that it can be deployed extremely easily, on a simple little low-powered
server or two, and will then provide largely bullet-proof DHCP service
*with failover*. It scales quite nicely from the small network up to a
quite large network - obviously it tops out somewhere, and people
needing real industrial strength move to something like the Nominum
products. But ISC DHCP is working well in tens of thousands of
installations of all different sizes right now. If it required a
(relatively) complex database back end, it would not serve the needs of
many as well as it does.

> > One down side is that you need all your DHCP servers to be the same;
> you lose interoperability. That may or may not be a problem.
> 
> Well no. There's this lovely layer of abstraction between the DHCP
> server and the database.

:-) You've missed my point a bit. I mean that if you have (say) an ISC
DHCP server in your network, you can't do DHCP failover with it unless
your server also speaks DHCP failover.

As to using SQL as a lingua franca, I can see a world of pain right
there. You would definitely need a standard to hold stuff together. Of
course, the standards process is there for all, so go for it :-)

> Our current production SQL server comes in at 0.0004 seconds for a
> SELECT statement against an indexed column containing 13,000 unique IP
> addresses. Insert statements will vary depending on the number 
> indexes defined. But should be less than 50ms absolute maximum...

So taking 50ms as a worst case (because almost all actions will involve
remembering state of some kind), you are looking at 20 DHCP
"transactions" per second. Let's be kind and say you get ten times that
- 200 per second. That doesn't seem much... see below.

> Is anyone actually using [DHCPv6]? What advantages does it have over
> the stateless auto-configuration protocol? (i've not really done that
> much reading as regards to IPv6 yet).

I'll put my potted response in a separate email.

> We have a subnet with ~3000 hosts. After a campus wide power failure,
> it is conceivable that they'd all be trying to acquire leases at the
> same time, especially once the distribution layer is UPS 
> backed. This would probably make the DHCP server sad.

Not to play my network is bigger than your network, but we've had power
outages that took out 30,000 clients. If they come back across (say) two
minutes, that's an average of 1000 DHCP messages per second (discover,
offer, request, ack). We've never had them all go, but we've had about a
quarter of them go at once. The Nominum servers dealt with it just fine.

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/20090609/d25a1b8e/attachment.pgp>