<html><head><title>Re: Failback causes lost lease</title>
<META http-equiv=Content-Type content="text/html; charset=windows-1252">
</head>
<body>
<br><br>
<table bgcolor="#ffffff">
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><span style=" font-family:'courier new'; font-size: 9pt;">Gregory,<br>
<br>
Thanks for your reply.<br>
<br>
On 06/25/2015 12:47 PM, Gregory Sloop wrote:<br>
Re: Failback causes lost lease <span style=" 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></span><a style=" font-family:'courier new'; font-size: 9pt;" href="mailto:dhcp-users@lists.isc.org">SM> dhcp-users@lists.isc.org</a><br>
<a 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>
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.</td>
</tr>
</table>
<span style=" font-family:'courier new'; font-size: 9pt;">But in your initial post on this thread you said: <br>
<br>
> "<span style=" color: #800000;"><b>After both the primary and secondary<br>
> had moved from communications-interrupted to normal"<br>
<br>
</b><span style=" color: #000000;">It can't be both ways. Either they are CI, or in a Normal state. It can't be both.<br>
Like I said, logs would probably be helpful. [Unless someone else has a lightening bolt moment and can tell you exactly what's wrong without them - but I doubt that.<br>
<br>
<br>
</span></span></span><table bgcolor="#ffffff">
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">As far as "tight IP pool" goes, it's the only ip in use in a /16 pool.</td>
</tr>
</table>
<br><br>
<span style=" font-family:'Courier New'; font-size: 9pt;">Yes, I expected as much. Further the symptoms you're having don't match, at all, what I'm describing. [No free leases is the result of my situation.]<br>
<br>
</span><table bgcolor="#ffffff">
<tr>
<td width=2 bgcolor= #0000ff><br>
</td>
<td><br><br>
<span style=" font-family:'courier new'; font-size: 9pt;">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>
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.</td>
</tr>
</table>
<br><br>
<span style=" font-family:'Courier New'; font-size: 9pt;">So, I'd ask for logs that demonstrate that:<br>
1) What real state both fail-over peers are actually in. [CI/Normal/recovery something else]<br>
2) Logs and/or packet caps that show the [primary] peer who initially leased the IP is actually getting the renew requests.<br>
3) Is this a really simple config setup? If not - and it appears to be a test environment - strip the config down to bare minimum. Then build up. It's quite easy to make a mistake in a config that borks everything up, whilst trying to do everything in one go. [Though I can't envision a mistake in a config that would produce these results/symptoms...but I'm far from a total guru on dhcpd.]<br>
<br>
My gut feeling is unchanged, in that there's some physical/data/network/transport layer issue that's preventing all the relevant traffic getting from clients to both peers, and perhaps even between the peers themselves. <br>
<br>
-Greg</body></html>