Re: [SLUG] dhcp server in support of my Thin Client attempt

From: Ian C. Blenke (icblenke@nks.net)
Date: Thu Sep 12 2002 - 09:55:19 EDT


On Wed, 2002-09-11 at 19:42, R P Herrold wrote:
> On 11 Sep 2002, Ian C. Blenke wrote:
>
> > Well, here's the thing: you really can't have more than one DHCP server
> > on a segment unless you statically add host entries by hand.
>
> ummm ... using the dhcpctl API or OMAPI, it is perfectly
> possible to configure automated multiple failover or load
> spreading dhcp servers on the same network segments and
> servicing the same subnets. The facility is readily available
> in dhcp-3 packaging. But not a task for a beginner.

DHCP Failover is still an IETF draft:

 http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-10.txt

Yes, DHCP 3.0 does support this - but if the failover does not function
correctly, you're basically in for a world of pain.

Let me clarify my earlier statement: DHCP client negotiation is a
BROADCAST protocol, and as such was only designed to work with ONE
server active on any given network segment AT ANY TIME. When a client
sends a DHCP request, it will use the lease from the first responding
DHCP server. When more than one DHCP server is giving out conflicting
leases to the same MAC, you have state issues that can (and generally
do) cause network difficulties. IP assignment collisions may occur as
well, unless DHCP servers are defined unique IP ranges.

Honestly, the only time this really makes much sense to implement is
when you're using DHCP helpers on remote routers on a large enterprise
network and have a centralized DHCP server. In this model, DHCP failover
makes sense.

- Ian C. Blenke <icblenke@nks.net> <ian@blenke.com>
http://ian.blenke.com



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:24:20 EDT