Secondary in failover pair does not perform dynamic DNS updates

[Matthew Kassawara]

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 at umich.edu> wrote:

>
> On Tue, Apr 4, 2017 at 2:29 PM, Matthew Kassawara <
> matthew.kassawara at 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 at thehobsons.co.uk>
>> wrote:
>>
>>> Matthew Kassawara <matthew.kassawara at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170405/63c47eb3/attachment.html>