Failover Pair handing out 2 different Addresses.

Randall C Grimshaw rgrimsha at
Mon Nov 2 19:14:40 UTC 2009

2 possibilities come to mind:

The peer of older 3.x versions is not going to practice mac-address-affinity so you may see the previous active server for an expired lease provide the same ipnumber as before and the peer offer something different. This is not considered broken, just irritating and I think is fixed in the 3.1.1

You should check however that the peer status of the pair is normal because an ntp failure resulting in clock drift can disconnect the peer pair and result in independent offers.


-----Original Message-----
From: dhcp-users-bounces at [mailto:dhcp-users-bounces at] On Behalf Of Martin McCormick
Sent: Monday, November 02, 2009 1:19 PM
To: Users of ISC DHCP
Subject: Failover Pair handing out 2 different Addresses.

	We have 261 defined networks on our DHCP failover pair
and all but 2 are behaving normally. We are concentrating on 1
of them because I think the problem is the same, what ever it

	The lease time is only 60 seconds because this is an
authentication network and people shouldn't be in it for very
long at a time but the problem is our primary and secondary are
handing out different addresses. At times, the primary sees the
DHCPDISCOVER and the secondary does not. At other times, the
secondary sees it a couple of seconds late. Here is the
configuration. It is identical for this portion of the
dhcpd.conf file on both servers:

subnet netmask {
option subnet-mask;
option routers;
option broadcast-address;
ddns-updates on;
option domain-name "auth-uhs.osu";
default-lease-time 60;
max-lease-time 60;
 pool {
deny dynamic bootp clients;
failover peer "stw";
} #end network

	I am really at a loss because 259 networks configured
the same way for different subnets can't be that wrong. Is there
anything else on the dhcp servers I can look at that I might
have overlooked?

	At one time today, someone actually did get both servers
to see the DHCPDISCOVER request at the same time but 2 different
IP addresses resulted. That was just seconds after one of the
usual Primary sees it but secondary didn't situations so they
may have still been out of sync with each other.

Any ideas? Many thanks.

Martin McCormick WB5AGZ  Stillwater, OK 
Systems Engineer
OSU Information Technology Department Telecommunications Services Group
dhcp-users mailing list
dhcp-users at

More information about the dhcp-users mailing list