DHCP Failover & Stuck Secondary Server

[Lang, Michael]

Hello everyone,

 

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?  Your comments & suggestions are greatly
appreciated.

 

-          Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080318/0fd4b07f/attachment.html>