DHCP code in 2.0.4+
Karl Auer
kauer at biplane.com.au
Tue Jun 9 05:51:27 CEST 2009
On Tue, 2009-06-09 at 04:15 +0200, Alan DeKok wrote:
> Karl Auer wrote:
> > 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
>
> That looks to me like fail-over has a well-agreed upon meaning for
> everything *other* than DHCP.
Yeah, you're probably right :-) But still.
> The fail-over protocol does not work. Full-stop.
Unless you come up with some very clever definition of "does not work",
that's just plain wrong, Alan. It clearly *does* work, most of the time
for most of the people, and has been doing so in enterprises large and
small for many years.
It's OK to exaggerate for emphasis, but your statement flies in the face
of years of real world experience with ISC DHCP and others.
The fact that I haven't had a serious failure in the last eight years or
so is a pretty good indicator to me that the protocol is robust
*enough*.
> If you think it works for you, it's because you've never ran into
> cases where it failed.
That is true of any protocol you care to name. It's also an unanswerable
non-argument. Does inspection of the DHCP failover protocol reveal a
theoretical failure mode to you? Or is it that the ISC DHCP
implementation that has exhibited failures? One thing is very different
to the other.
> Or, the implementation you're using doesn't
> follow the protocol as documented.
That's possible. That never occurred to me, because it is allegedly
interoperable with ISC DHCP. I will ask!
> Where "failover" is defined as "sometimes works".
It almost always works. It works *by far* most of the time. Even with
ISC DHCP. To the point where I have not ever seen it fail except due to
bugs in an implementation. My experience is not all-encompassing -
perhaps you have seen it fail when the protocol was properly
implemented.
> If you look at the design of FreeRADIUS, you see a better way to do
> things. FreeRADIUS doesn't *require* a DB. But if you have one, it
> uses it.
Yep, no argument there at all. Almost any software is more scalable on a
DB than on text files, not to mention easier to maintain, extend,
configure, back up, administer....
> A public SQL schema. That's it.
There's a bit more to interoperability than merely a public schema. You
need a public schema that everyone agrees to use, and that everyone
agrees is at least a good schema. That means a standard. This is
particularly important for deployment in government and large
enterprises. If you are quick and lucky and have a good product, your
schema might become a de-facto standard, of course.
> ISC doesn't deal with that situation very well. At least part of the
> issue is the delays due to the failover protocol.
Yes. Or rather, it's delays in the operation of the failover protocol as
implemented in ISC DHCP. Or I believe it to be - feel free to educate me
otherwise.
> And I'll get money that Nominum is getting such high performance by
> doing the kind of optimizations I'm talking about.
That could be. That is, their failover implementation may not follow the
draft standard. However, if they were going to go non-standard, why not
develop their own mechanism entirely? But I will ask them about this.
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/798c3793/attachment.pgp>
More information about the Freeradius-Users
mailing list