DHCP Failover & Stuck Secondary Server
mike.lang at uconn.edu
Wed Mar 26 15:13:10 UTC 2008
Thanks to those who responded to me. I finally figured out what was causing me all the trouble and thought I would share it. Someone had configured the 'server-identifier' option with the IP of the old dhcp server that had been broken off. So although the clients were heading to the right pair of DHCP servers, the failover DHCP server was telling clients to go to the decommissioned server! Once I fixed this error it took the length of max lease time for everyone to finally abandon the old server. All is good now.
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf Of Simon Hobson
Sent: Tuesday, March 18, 2008 12:10 PM
To: dhcp-users at isc.org
Subject: Re: DHCP Failover & Stuck Secondary Server
Lang, Michael wrote:
>I'm having trouble with our DHCP Server
>infrastructure. A decommissioned DHCP server is
>still receiving a bunch of requests and we've
>had IP conflicts as the result of having
>separate DHCP servers running for a while.
>Here is what happenedŠ
>We moved from a single DHCP server setup to a
>new failover scenario, running v3.0.3. The
>initial migration worked well, we brought down
>the old server, moved the appropriate files and
>then changed IPs and brought the new guy up. At
>this point everything is great. Next, and here
>is the beginning of the mistake, we tested the
>failover with the old DHCP server which was
>moved on a different IP. At this point, the
>servers probably balanced the load so both were
>working. We never advertised the new IP on the
>old server as a helper, but plenty of people
>were served by it. Once we believed we knew how
>to configure backup, we setup the new backup
>server and configured the two new servers to
>work between each other. So at this point now
>we have the primary/backup pair working and the
>old DHCP server (in failover mode broken from
>the primary) is still serving leases, waiting
>for the primary to come back online with it -
>which will never happen.
>Now, I've tried to get clients to move to the
>proper pair with two separate actions, both with
>mixed success. First, I configured that server
>to NAK all requests by changing the pools to
>'deny known clients' and 'deny unknown clients'.
>This caused about half the users to move to
>correct servers. The next action I took was to
>shut off the DHCP service, this was over a week
>ago and I'm still getting thousands of requests
>to the box - verified using tcpdump.
>My question is, is there a way that I can
>configure the old DHCP server so that it will
>respond in a manner that will force clients to
>move to the correct DHCP server pair?
No, they will move of their own accord and you
should do nothing except make sure the DHCP
service does NOT run on the old box. It will
still get renewal requests from any clients that
previously had a lease from it and these may
continue until all leases it issued have expired
- there is no mechanism to "take back" a lease.
Also, clients do not know about failover and
there is no way to tell them about a backup DHCP
The clients will eventually stop unicasting for
lease renewals and broadcast them. At this point,
the new servers will be able to offer a lease.
Typically, a client will send a renewal request
to the server at half the lease time. Later
(default 7/8th of the lease time IIRC), they will
start to broadcast the renewal request. If the
lease expires altogether the client should stop
using the address until it can get a new lease.
The behavior differs between clients. Some
(notably Windows) will continue to use an
unexpired lease if they detect that they are on
the same network that they were on when they got
the lease (I believe they check if the default
router is the same). Others, notably most
'appliance' type devices without persistent
storage and/or clock, will simply broadcast for a
lease each time they boot - and they will already
have switched servers.
More information about the dhcp-users