Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Procedure for failover partner replacement. (Bob McDonald)
2. Re: Procedure for failover partner replacement. (perl-list)
3. Re: Procedure for failover partner replacement. (Chris Buxton)
4. Re: Procedure for failover partner replacement. (perl-list)
5. Re: Procedure for failover partner replacement. (Chris Buxton)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 May 2017 08:35:42 -0500
From: Bob McDonald <bmcdonal...@gmail.com>
To: dhcp-users@lists.isc.org
Subject: Procedure for failover partner replacement.
Message-ID:
<cam-yptderkoxh3wxoe66_2poxfyq00lzdgq+oxc1k-cagiv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've got a failing dhcp failover partner. (the partner is a HA cluster and
both nodes are being RMAed. Long story)
My question is this. Is the following procedure ok for the replacement?
(I've already confirmed the new version of DHCP is exactly the same as the
old one)
1) before shutting down the failing partner cluster, stop DHCP and save the
dhcpd.leases file and the DHCPD.conf file.
2) shut down the failing partner cluster completely.
3) bring up the replacement partner cluster while leaving DHCPD turmed off.
4) restore the DHCPD.leases and DHCPD.conf files.
5) restart DHPCD on the replacement partner cluster.
My contention is that this will result in the failover pair going into
partner-interrupted state for about 5 or 10 minutes while the HA cluster is
replaced and then should restart communications as if nothing happened when
the replacement partner comes live. Thoughts?
Regards,
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20170511/215069bb/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 11 May 2017 10:00:09 -0400 (EDT)
From: perl-list <perl-l...@network1.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Procedure for failover partner replacement.
Message-ID:
<129576090.601434.1494511209346.javamail.zim...@network1.net>
Content-Type: text/plain; charset="utf-8"
If you are using the same version of DHCP, then it should work fine.
I have done exactly that before and it has worked for me. The DHCP servers
returned to both partners normal mode after a very brief (not responding
startup) state. The DHCP servers did not appear to in any way realize they were
on a different cluster.
> From: "Bob McDonald" <bmcdonal...@gmail.com>
> To: dhcp-users@lists.isc.org
> Sent: Thursday, May 11, 2017 9:35:42 AM
> Subject: Procedure for failover partner replacement.
> I've got a failing dhcp failover partner. (the partner is a HA cluster and
> both
> nodes are being RMAed. Long story)
> My question is this. Is the following procedure ok for the replacement? (I've
> already confirmed the new version of DHCP is exactly the same as the old one)
> 1) before shutting down the failing partner cluster, stop DHCP and save the
> dhcpd.leases file and the DHCPD.conf file.
> 2) shut down the failing partner cluster completely.
> 3) bring up the replacement partner cluster while leaving DHCPD turmed off.
> 4) restore the DHCPD.leases and DHCPD.conf files.
> 5) restart DHPCD on the replacement partner cluster.
> My contention is that this will result in the failover pair going into
> partner-interrupted state for about 5 or 10 minutes while the HA cluster is
> replaced and then should restart communications as if nothing happened when
> the
> replacement partner comes live. Thoughts?
> Regards,
> Bob
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@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/20170511/2e0ec4b6/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 11 May 2017 07:38:48 -0700
From: Chris Buxton <cli...@buxtonfamily.us>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Procedure for failover partner replacement.
Message-ID: <aaab2cca-088d-4326-9959-f73f4d11b...@buxtonfamily.us>
Content-Type: text/plain; charset=us-ascii
On May 11, 2017, at 6:35 AM, Bob McDonald <bmcdonal...@gmail.com> wrote:
>
> I've got a failing dhcp failover partner. (the partner is a HA cluster and
> both nodes are being RMAed. Long story)
>
> My question is this. Is the following procedure ok for the replacement? (I've
> already confirmed the new version of DHCP is exactly the same as the old one)
>
> 1) before shutting down the failing partner cluster, stop DHCP and save the
> dhcpd.leases file and the DHCPD.conf file.
> 2) shut down the failing partner cluster completely.
> 3) bring up the replacement partner cluster while leaving DHCPD turmed off.
> 4) restore the DHCPD.leases and DHCPD.conf files.
> 5) restart DHPCD on the replacement partner cluster.
>
> My contention is that this will result in the failover pair going into
> partner-interrupted state for about 5 or 10 minutes while the HA cluster is
> replaced and then should restart communications as if nothing happened when
> the replacement partner comes live. Thoughts?
Here is what I would do:
1. On both failover peers (both clusters), set 'max-unacked-updates 1000;'.
2. Save the old dhcpd.conf and any included files from the failing peer
cluster. Do not save the leases file.
3. Shut down the failing cluster completely.
4. Put the remaining failover peer into partner-down state.
5. Bring up the replacement cluster with dhcpd not running.
6. Restore the dhcpd.conf (including the 'max-unacked-updates' statement.
7. Start dhcpd on the replacement cluster.
At step 3, the remaining peer will move to communications-interrupted. But step
4 will change this, so that you don't have to worry about pool exhaustion
during steps 5 and 6. At step 7, the new peer will move to recover state, sync
with the master, and then move to normal state. At that point, the other peer
will automatically move from partner-down to normal state.
Regards,
Chris
------------------------------
Message: 4
Date: Thu, 11 May 2017 11:17:37 -0400 (EDT)
From: perl-list <perl-l...@network1.net>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Procedure for failover partner replacement.
Message-ID:
<2120140484.602208.1494515857220.javamail.zim...@network1.net>
Content-Type: text/plain; charset="utf-8"
That is an interesting idea, Chris, but in my experience both peers will enter
recover mode at step 7 and won't answer dhcp requests until the recover-wait
(MCLT) period expires or you manually intervene... as always YMMV
> From: "Chris Buxton" <cli...@buxtonfamily.us>
> To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
> Sent: Thursday, May 11, 2017 10:38:48 AM
> Subject: Re: Procedure for failover partner replacement.
> On May 11, 2017, at 6:35 AM, Bob McDonald <bmcdonal...@gmail.com> wrote:
>> I've got a failing dhcp failover partner. (the partner is a HA cluster and
>> both
> > nodes are being RMAed. Long story)
>> My question is this. Is the following procedure ok for the replacement? (I've
> > already confirmed the new version of DHCP is exactly the same as the old
> > one)
>> 1) before shutting down the failing partner cluster, stop DHCP and save the
> > dhcpd.leases file and the DHCPD.conf file.
> > 2) shut down the failing partner cluster completely.
> > 3) bring up the replacement partner cluster while leaving DHCPD turmed off.
> > 4) restore the DHCPD.leases and DHCPD.conf files.
> > 5) restart DHPCD on the replacement partner cluster.
>> My contention is that this will result in the failover pair going into
>> partner-interrupted state for about 5 or 10 minutes while the HA cluster is
>> replaced and then should restart communications as if nothing happened when
>> the
> > replacement partner comes live. Thoughts?
> Here is what I would do:
> 1. On both failover peers (both clusters), set 'max-unacked-updates 1000;'.
> 2. Save the old dhcpd.conf and any included files from the failing peer
> cluster.
> Do not save the leases file.
> 3. Shut down the failing cluster completely.
> 4. Put the remaining failover peer into partner-down state.
> 5. Bring up the replacement cluster with dhcpd not running.
> 6. Restore the dhcpd.conf (including the 'max-unacked-updates' statement.
> 7. Start dhcpd on the replacement cluster.
> At step 3, the remaining peer will move to communications-interrupted. But
> step
> 4 will change this, so that you don't have to worry about pool exhaustion
> during steps 5 and 6. At step 7, the new peer will move to recover state, sync
> with the master, and then move to normal state. At that point, the other peer
> will automatically move from partner-down to normal state.
> Regards,
> Chris
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@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/20170511/2b500060/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 11 May 2017 15:22:07 -0700
From: Chris Buxton <cli...@buxtonfamily.us>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Procedure for failover partner replacement.
Message-ID: <f79ee12a-17db-4026-ad8a-8e96d43bf...@buxtonfamily.us>
Content-Type: text/plain; charset="us-ascii"
As long as you've put the remaining server into partner-down state, it will
remain there until its peer has finished recovery.
Regards,
Chris
> On May 11, 2017, at 8:17 AM, perl-list <perl-l...@network1.net> wrote:
>
> That is an interesting idea, Chris, but in my experience both peers will
> enter recover mode at step 7 and won't answer dhcp requests until the
> recover-wait (MCLT) period expires or you manually intervene... as always
> YMMV
>
>
> From: "Chris Buxton" <cli...@buxtonfamily.us>
> To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
> Sent: Thursday, May 11, 2017 10:38:48 AM
> Subject: Re: Procedure for failover partner replacement.
> On May 11, 2017, at 6:35 AM, Bob McDonald <bmcdonal...@gmail.com> wrote:
> >
> > I've got a failing dhcp failover partner. (the partner is a HA cluster and
> > both nodes are being RMAed. Long story)
> >
> > My question is this. Is the following procedure ok for the replacement?
> > (I've already confirmed the new version of DHCP is exactly the same as the
> > old one)
> >
> > 1) before shutting down the failing partner cluster, stop DHCP and save the
> > dhcpd.leases file and the DHCPD.conf file.
> > 2) shut down the failing partner cluster completely.
> > 3) bring up the replacement partner cluster while leaving DHCPD turmed off.
> > 4) restore the DHCPD.leases and DHCPD.conf files.
> > 5) restart DHPCD on the replacement partner cluster.
> >
> > My contention is that this will result in the failover pair going into
> > partner-interrupted state for about 5 or 10 minutes while the HA cluster is
> > replaced and then should restart communications as if nothing happened when
> > the replacement partner comes live. Thoughts?
>
> Here is what I would do:
>
> 1. On both failover peers (both clusters), set 'max-unacked-updates 1000;'.
> 2. Save the old dhcpd.conf and any included files from the failing peer
> cluster. Do not save the leases file.
> 3. Shut down the failing cluster completely.
> 4. Put the remaining failover peer into partner-down state.
> 5. Bring up the replacement cluster with dhcpd not running.
> 6. Restore the dhcpd.conf (including the 'max-unacked-updates' statement.
> 7. Start dhcpd on the replacement cluster.
>
> At step 3, the remaining peer will move to communications-interrupted. But
> step 4 will change this, so that you don't have to worry about pool
> exhaustion during steps 5 and 6. At step 7, the new peer will move to recover
> state, sync with the master, and then move to normal state. At that point,
> the other peer will automatically move from partner-down to normal state.
>
> Regards,
> Chris
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users@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/20170511/90d9eb4d/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 103, Issue 2
******************************************
