Secondary in failover pair does not perform dynamic DNS updates

[Matthew Kassawara]

Hi,

I am trying to deploy DHCPD (4.3.3) with dynamic DNS in a failover pair. During normal operation, the primary DHCPD instance performs all dynamic DNS updates regardless of which peer appears to own a particular lease. If I simulate failure of the primary DHCPD instance, the secondary DHCPD instance does not perform dynamic DNS updates. Dynamic DNS updates for new leases or renewals that occur during a failover condition wait until I restore the primary DHCPD instance and it receives a renewal request for a lease that involves dynamic DNS records. Should the secondary DHCP instance perform dynamic DNS updates in one or more failover states?

Thanks,

Matt

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Matthew Kassawara <[hidden email]> wrote:

> If I simulate failure of the primary DHCPD instance

Are you doing that properly, and putting the peer into partner down state ?

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Matthew Kassawara]

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 <[hidden email]> wrote:

Matthew Kassawara <[hidden email]> wrote:

> If I simulate failure of the primary DHCPD instance

Are you doing that properly, and putting the peer into partner down state ?

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Bob Harold]

On Tue, Apr 4, 2017 at 2:29 PM, Matthew Kassawara <[hidden email]> 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 <[hidden email]> wrote:

Matthew Kassawara <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[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 <[hidden email]> wrote:

On Tue, Apr 4, 2017 at 2:29 PM, Matthew Kassawara <[hidden email]> 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 <[hidden email]> wrote:

Matthew Kassawara <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users