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 ([email protected]) +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
signature.asc
Description: This is a digitally signed message part
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
