<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Gregory,<br>
<br>
Thanks for your reply.<br>
<br>
<div class="moz-cite-prefix">On 06/25/2015 12:47 PM, Gregory Sloop
wrote:<br>
</div>
<blockquote cite="mid:472757097.20150625124759@sloop.net"
type="cite">
<title>Re: Failback causes lost lease</title>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<span style=" font-family:'courier new'; font-size: 9pt; color:
#800000;"><b>SM> In testing my dhcp failover, I pulled the
ethernet cable on the primary<br>
SM> server.<br>
<br>
SM> The secondary server acknowleged renewal requests as
expected.<br>
<br>
SM> Then I plugged the cable back in. After both the
primary and secondary<br>
SM> had moved from communications-interrupted to normal,
the secondary logs<br>
SM> multiple dhcp requests from a client whose lease is
owned by the primary<br>
SM> server. The primary server does not log any of these
but the last <br>
SM> request, reporting that "lease in transition state
expired".<br>
<br>
SM> Then the secondary server logs a DHCPDISCOVER from that
client and <br>
SM> records it load balancing to the primary server.<br>
<br>
SM> The primary server also sees the DHCPDISCOVER and
offers a new lease <br>
SM> that is not the same number as the previous lease. This
despite the old<br>
SM> number not having been reassigned.<br>
<br>
SM> The end result is that failback causes my clients to
change their ip <br>
SM> address.<br>
<br>
SM> Why does this happen and how can I prevent it?<br>
<br>
SM> _______________________________________________<br>
SM> dhcp-users mailing list<br>
</b></span><a moz-do-not-send="true" style="
font-family:'courier new'; font-size: 9pt;"
href="mailto:dhcp-users@lists.isc.org">SM>
dhcp-users@lists.isc.org</a><br>
<a moz-do-not-send="true" style=" font-family:'courier new';
font-size: 9pt;"
href="https://lists.isc.org/mailman/listinfo/dhcp-users">SM>
https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
<br>
<span style=" font-family:'Courier New'; font-size: 9pt;">1) Logs
would be good.<br>
2) I think something with your config is broken. If I were to
[wildly] guess, it's a physical/network layer issue.<br>
3) I have a very small setup with 100+ clients, and it certainly
doesn't work this way for me. <br>
<br>
There are some issues when a single server is up and in
"communications interrupted" mode and you've got a tight IP pool
and the leases were fairly evenly balanced against both servers.
[I've posted, in the past, about an event that was kinda ugly
for this client while running a 4.1 version [IIRC]. *However*
those problems should be vastly less of a problem with 4.2+ -
and you're not having an issue with communications interrupted
anyway.<br>
</span></blockquote>
I am having an issue with communications interrupted. When I pull
the ethernet cable, both the primary and secondary servers move from
normal to communications-interrupted.<br>
<br>
As far as "tight IP pool" goes, it's the only ip in use in a /16
pool.<br>
<blockquote cite="mid:472757097.20150625124759@sloop.net"
type="cite"><span style=" font-family:'Courier New'; font-size:
9pt;">
<br>
IIRC, you had a problem where the two servers wouldn't recover
from CI to Normal like they should too. How did you solve that
problem? Is it possible this is related? [I'm too lazy to go
check old threads, but I _think_ it was you...my apologies if
I'm wrong.]<br>
</span></blockquote>
That was a stupid networking mistake where the failover traffic
wasn't making it between peers. That problem was solved when I quit
being so stupid. In this case, the peers are communicating failover
data correctly when not in "communications-interrupted" stage.<br>
</body>
</html>