Failover stability (peer holds all free leases)

[Keith Lawson]

>>>Glenn.Satchell at uniq.com.au 07/05/06 6:33 am >>> 
 
>>Date: Tue, 04 Jul 2006 14:05:13 -0400 
>>From: "Keith Lawson" <Keith.Lawson at sjhc.london.on.ca> 
>>To: <dhcp-users at isc.org> 
>>Subject: Failover stability? 
>> 
>>Hello, 
>> 
>>I'm just wondering what the state is of master/slave peer failover. Is

>>failover stable enough to be used in a production environment now? 
>> 
>>I've been testing using 3.0.4 one one subnet  and I'm running into a 
>>scenario where the master load balances a request to the slave. The 
>>slave then ignores the request and logs a "peer holds all free leases"

>>message. I've been reading through the mailing list archives and 
>>indications are that these problems are supposed to be resolved in
3.0.4 
>>but that doesn't seem to be the case. 
>> 
> 
>I've been running failover for over 5 years (since 3.0.1rc6) on a site 
>with 3500 PCs and 4500 IP phones, so I think it's perfectly 
>satisfactory for production use. 
> 
>regards, 
>-glenn 
 
 
Hello, 

Here's the scenerio I seem to be running into while testing: 

- win2k pc gets a lease
- manually release that lease
- when I attempt to renew, primary server gets DHCPREQUEST and sends a
DHCPACK. Then I see a DHCPDISCOVER message from the client that gets
load balanced to the slave server. 
- The slave server sees a DHCPREQUEST for an IP that the master holds so
sends a DHCPNAK message.

Shouldn't the client accept the first DHCPACK and never send the
DISCOVER message? 

Both DHCP servers are on the same subnet and both are in as helper
addresses right now.

Thanks, 
Keith.

-----------------------------------------
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended
recipient is prohibited. If you received this in error, please
contact the sender and delete the material from any computer.
www.sjhc.london.on.ca