[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-users
Subject:    Re: Secondary in failover pair does not perform dynamic DNS updates
From:       Matthew Kassawara <matthew.kassawara () blinker ! com>
Date:       2017-04-05 15:00:16
Message-ID: CANpQwzJfGacSPx4RMNJU1iCL=NVN6JhamCV1rQYF+ed7WGH05w () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


If I set "local-state" on the primary peer to "shut_down" (8), the
secondary peer immediately assumes a "local-state" of "partner_down" (4)
and a "partner-state" of "shut_down" (8).

Interestingly, the problem went away after I began testing different
(lower) MCLT values. I also can't reproduce it using the original MCLT
value. I think one or both lease database files gained some cruft during
the initial configuration and testing process that eventually worked itself
out. Additionally, both peers operate normally after purging the lease
database files.

Thanks for the help!



On Tue, Apr 4, 2017 at 1:16 PM, Bob Harold <rharolde@umich.edu> wrote:

>
> On Tue, Apr 4, 2017 at 2:29 PM, Matthew Kassawara <
> matthew.kassawara@blinker.com> wrote:
>
>> Neither stopping the primary peer (resulting in a
>> "communications_interrupted" state on the secondary peer) nor changing the
>> primary peer state to "partner_down" via OMAPI cause the secondary peer to
>> perform dynamic DNS updates.
>>
>> On Tue, Apr 4, 2017 at 12:22 PM, Simon Hobson <dhcp1@thehobsons.co.uk>
>> wrote:
>>
>>> Matthew Kassawara <matthew.kassawara@blinker.com> wrote:
>>>
>>> > If I simulate failure of the primary DHCPD instance
>>>
>>> Are you doing that properly, and putting the peer into partner down
>>> state ?
>>>
>>>
>>
> You need to do "partner_down" on the secondary (telling it the primary is
> down).  It might get to that state after waiting the MCLT time (typically a
> half hour ?) but I am not sure.  So "complete" failover is a manual process.
>
> --
> Bob Harold
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

[Attachment #5 (text/html)]

<div dir="ltr">If I set &quot;local-state&quot; on the primary peer to \
&quot;shut_down&quot; (8), the secondary peer immediately assumes a \
&quot;local-state&quot; of &quot;partner_down&quot; (4) and a \
&quot;partner-state&quot; of &quot;shut_down&quot; \
(8).<div><br></div><div>Interestingly, the problem went away after I began testing \
different (lower) MCLT values. I also can&#39;t reproduce it using the original MCLT \
value. I think one or both lease database files gained some cruft during the initial \
configuration and testing process that eventually worked itself out. Additionally, \
both peers operate normally after purging the lease database \
files.</div><div><br></div><div>Thanks for the \
help!<br><div><div><br></div><div><br></div></div></div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 4, 2017 at 1:16 PM, Bob \
Harold <span dir="ltr">&lt;<a href="mailto:rharolde@umich.edu" \
target="_blank">rharolde@umich.edu</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div \
class="gmail_quote"><span class="">On Tue, Apr 4, 2017 at 2:29 PM, Matthew Kassawara \
<span dir="ltr">&lt;<a href="mailto:matthew.kassawara@blinker.com" \
target="_blank">matthew.kassawara@blinker.com</a><wbr>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Neither \
stopping the primary peer (resulting in a &quot;communications_interrupted&quot; \
state on the secondary peer) nor changing the primary peer state to \
&quot;partner_down&quot; via OMAPI cause the secondary peer to perform dynamic DNS \
updates.</div><div class="m_1656037030053972631gmail-HOEnZb"><div \
class="m_1656037030053972631gmail-h5"><div class="gmail_extra"><br><div \
class="gmail_quote">On Tue, Apr 4, 2017 at 12:22 PM, Simon Hobson <span \
dir="ltr">&lt;<a href="mailto:dhcp1@thehobsons.co.uk" \
target="_blank">dhcp1@thehobsons.co.uk</a>&gt;</span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><span>Matthew Kassawara &lt;<a \
href="mailto:matthew.kassawara@blinker.com" \
target="_blank">matthew.kassawara@blinker.com</a><wbr>&gt; wrote:<br> <br>
&gt; If I simulate failure of the primary DHCPD instance<br>
<br>
</span>Are you doing that properly, and putting the peer into partner down state \
?<br> <br>
</blockquote></div></div></div></div><br></blockquote><div><br></div></span><div>You \
need to do &quot;partner_down&quot; on the secondary (telling it the primary is \
down).   It might get to that state after waiting the MCLT time (typically a half \
hour ?) but I am not sure.   So &quot;complete&quot; failover is a manual \
process.</div></div><span class="HOEnZb"><font \
color="#888888"><br></font></span></div><span class="HOEnZb"><font \
color="#888888"><div class="gmail_extra">--  </div><div class="gmail_extra">Bob \
Harold</div><div class="gmail_extra"><br></div></font></span></div> \
<br>______________________________<wbr>_________________<br> dhcp-users mailing \
list<br> <a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" rel="noreferrer" \
target="_blank">https://lists.isc.org/mailman/<wbr>listinfo/dhcp-users</a><br></blockquote></div><br></div>




_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic