Ok, but that would not explain why hosts that have MAC address that match the hardware address and the start time after the end time were having problems until the lease file was re-written...both server were operating fine for renewals and some discoveries...just some clients that seemed to match as being off for awhile and then coming back and had their lease start time > lease ends...<br>
<br>Jonathan Brockmeier<br><br><div class="gmail_quote">On Wed, Apr 2, 2008 at 6:44 AM, Glenn Satchell <<a href="mailto:Glenn.Satchell@uniq.com.au">Glenn.Satchell@uniq.com.au</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
>Date: Tue, 1 Apr 2008 20:58:53 -0400<br>
>From: "Jonathan Brockmeier" <<a href="mailto:brockj@hope.edu">brockj@hope.edu</a>><br>
>To: <a href="mailto:dhcp-users@isc.org">dhcp-users@isc.org</a><br>
>Subject: Broken Failovers?<br>
<div class="Ih2E3d">><br>
>I think I have found out that I have been running with broken failover for<br>
>over a year:<br>
><br>
>From Server A:<br>
>failover peer "PEERNAME" state {<br>
>  my state normal at 4 2008/03/20 12:49:19;<br>
>  partner state normal at 1 2007/02/12 19:41:32;<br>
>}<br>
><br>
>From Server B:<br>
>failover peer "PEERNAME" state {<br>
>  my state normal at 4 2008/03/20 12:49:28;<br>
>  partner state normal at 1 2007/02/12 19:41:48;<br>
>  mclt 600;<br>
>}<br>
<br>
</div>This is a feature :) The partner state date is filled in the first time<br>
the lease file is written, and then nothing ever refers to it again. So<br>
your failover isn't broken. I'm sure that if you search the archives<br>
for "partner state normal" you'll find a few references.<br>
<br>
If you look in the syslog file (varies with different operating<br>
systems) you'll see what the current state is.<br>
<div class="Ih2E3d"><br>
>Also it looks like when I get "pool request" messages the leases that seemed<br>
>to be moved go into a state that they are locked for awhile (same on both<br>
>servers)<br>
>lease aaa.bbb.ccc.ddd {<br>
>  starts 2 2008/04/01 20:08:04;<br>
>  ends 2 2008/04/01 18:23:13;<br>
>  tstp 2 2008/04/01 18:23:13;<br>
>  tsfp 2 2008/04/01 20:08:04;<br>
>  cltt 2 2008/04/01 18:13:13;<br>
>  binding state backup;<br>
>  hardware ethernet 00:c0:17:31:38:8b;<br>
>  uid "\001\000\300\02718\213";<br>
>}<br>
><br>
>I would assume due to state 4 or is this related to some of the failover bug<br>
>fixes since 3.0.3?<br>
><br>
>If this is related to failover recovery not working for over a year, what is<br>
>the best way to recover since the servers are "working" for most clients<br>
>most of the time.<br>
<br>
</div>binding state backup means that the lease is available to be allocated<br>
by the secondary. That's quite normal. Different releases have juggled<br>
this around a bit, but since about 3.0.5 (I think) it tries to leave<br>
leases with the one host, rather than bouncong them between the two<br>
servers.<br>
<br>
The dhcpd.leases man page explains what all the fields are.<br>
<br>
regards,<br>
<font color="#888888">-glenn<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Jonathan Brockmeier, CIT<br>Hope College<br>616-395-7670