ISC DHCP Users

How to properly break DHCPd failover peer relationship

Classic

List

Threaded

4 messages Options

Justin Sanderson

How to properly break DHCPd failover peer relationship

This post was updated on .

Hi everyone. I'm new to the list and am in need of some advice.

I have 2 servers running RHEL 5.x using dhcp-3.0.5-23 that are running in a
peer relationship.

I'm looking for the best/easiest method to break this peer relationship and
reduce the dhcp server functionality back to just one server w/o
interrupting clients.

Again, any advice or past experiences would be helpful.

Here's a snippet of the conf files where the pool is being balanced/split.

================================================
PRIMARY SERVER
subnet 172.20.10.0 netmask 255.255.255.0 {
pool {
range 172.20.10.1 172.20.10.45;
range 172.20.10.47 172.20.10.95;
range 172.20.10.97 172.20.10.149;
ping-check true;
option subnet-mask 255.255.255.0;
option broadcast-address 172.20.10.255;
option routers 172.20.10.254;
deny dynamic bootp clients;
failover peer "xxxxx";
}
}
=======================================================
PRIMARY SERVER
failover peer "xxxxx" {
primary;
address 172.20.10.200;
port 520;
peer address 172.20.10.201;
peer port 521;
max-response-delay 120;
max-unacked-updates 10;
mclt 1800;
split 128;
load balance max seconds 3;
}

=========================================================

SECONDARY SERVER (the server i want to remove from the relationship)

subnet 172.20.10.0 netmask 255.255.255.0 {
pool {
range 172.20.10.1 172.20.10.45;
range 172.20.10.47 172.20.10.95;
range 172.20.10.97 172.20.10.149;
ping-check true;
option subnet-mask 255.255.255.0;
option broadcast-address 172.20.10.255;
option routers 172.20.10.254;
deny dynamic bootp clients;
failover peer "xxxxx";
}
}
==============================================================
SECONDARY SERVER

failover peer "xxxxx" {
secondary;
address 172.20.10.201;
port 521;
peer address 172.20.10.200;
peer port 520;
max-response-delay 120;
max-unacked-updates 10;
load balance max seconds 3;
}

ThankS in advance.

Regards,
Justin

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

Bob Harold

Re: How to properly break DHCPd failover peer relationship

On Mon, Mar 12, 2018 at 5:23 PM, Justin Sanderson <[hidden email]> wrote:

Hi everyone. I'm new to the list and am in need of some advice.

I have 2 servers running RHEL 5.x using dhcp-3.0.5-23 that are running in a peer relationship.

I'm looking for the best/easiest method to break this peer relationship and reduce the dhcp server functionality back to just one server w/o interrupting clients.

Again, any advice or past experiences would be helpful.

Here's a snippet of the conf files where the pool is being balanced/split.

================================================
PRIMARY SERVER
subnet 172.20.10.0 netmask 255.255.255.0 {
        pool {
                range 172.20.10.1 172.20.10.45;
                range 172.20.10.47 172.20.10.95;
                range 172.20.10.97 172.20.10.149;
                ping-check true;
                option subnet-mask 255.255.255.0;
                option broadcast-address 172.20.10.255;
                option routers 172.20.10.254;
                deny dynamic bootp clients;
                failover peer "xxxxx";
        }
}
=======================================================
PRIMARY SERVER
failover peer "xxxxx" {
        primary;
        address 172.20.10.200;
        port 520;
        peer address 172.20.10.201;
        peer port 521;
        max-response-delay 120;
        max-unacked-updates 10;
        mclt 1800;
        split 128;
        load balance max seconds 3;
}

=========================================================

SECONDARY SERVER (the server i want to remove from the relationship)

subnet 172.20.10.0 netmask 255.255.255.0 {
        pool {
                range 172.20.10.1 172.20.10.45;
                range 172.20.10.47 172.20.10.95;
                range 172.20.10.97 172.20.10.149;
                ping-check true;
                option subnet-mask 255.255.255.0;
                option broadcast-address 172.20.10.255;
                option routers 172.20.10.254;
                deny dynamic bootp clients;
                failover peer "xxxxx";
        }
}
==============================================================
SECONDARY SERVER

failover peer "adtran" {
        secondary;
        address 172.20.10.201;
        port 521;
        peer address 172.20.10.200;
        peer port 520;
        max-response-delay 120;
        max-unacked-updates 10;
        load balance max seconds 3;
}

ThankS in advance.

Regards,
Justin

I would suggest these steps:

1. On the failover server, stop the DHCP process.

2. On the primary server, put in "partner down" mode. (I don't have the exact command in front of me, I think you use omshell.)

3. Wait for as long as your longest lease time. You can watch the clients do DHCPREQUESTs to the failover server from half the lease time to 7/8, and then DHCPDISCOVER and get the lease renewed from the primary server.

4. Reconfigure the primary server without the failover options.

Bob Harold

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

Steven Carr

Re: How to properly break DHCPd failover peer relationship

On 13 March 2018 at 13:25, Bob Harold <[hidden email]> wrote:
> I would suggest these steps:
>
> 1. On the failover server, stop the DHCP process.
> 2. On the primary server, put in "partner down" mode. (I don't have the
> exact command in front of me, I think you use omshell.)
> 3. Wait for as long as your longest lease time. You can watch the clients
> do DHCPREQUESTs to the failover server from half the lease time to 7/8, and
> then DHCPDISCOVER and get the lease renewed from the primary server.
> 4. Reconfigure the primary server without the failover options.

As long as they are both up they should be in sync with each other,
and both systems have a full copy of the leases, so no need to use
partner down - it could actually cause you more pain to put it into
partner down if you are close to running out of leases in any pools -
on entering partner down you have to wait MCLT before you take over
the other addresses.

Just remove any mention of failover from the primary configuration,
shut down the secondary, restart the primary, remove any IP helpers
pointing to the secondary.

And of course, goes without saying, do this in a maintenance window.

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

Bill Shirley-2

Re: How to properly break DHCPd failover peer relationship

I agree. Also, you should remove the failover preamble from /var/lib/dhcpd/dhcpd.leases
before restarting the master:
failover peer "dhcp-failover" state { my state normal at 1 2018/03/12 11:30:52; partner state normal at 1 2018/03/12 11:30:52;}
Bill

On 3/14/2018 10:21 AM, Steven Carr wrote:

On 13 March 2018 at 13:25, Bob Harold [hidden email] wrote:

I would suggest these steps:

1. On the failover server, stop the DHCP process.
2. On the primary server, put in "partner down" mode.  (I don't have the
exact command in front of me, I think you use omshell.)
3. Wait for as long as your longest lease time.  You can watch the clients
do DHCPREQUESTs to the failover server from half the lease time to 7/8, and
then DHCPDISCOVER and get the lease renewed from the primary server.
4. Reconfigure the primary server without the failover options.

As long as they are both up they should be in sync with each other,
and both systems have a full copy of the leases, so no need to use
partner down - it could actually cause you more pain to put it into
partner down if you are close to running out of leases in any pools -
on entering partner down you have to wait MCLT before you take over
the other addresses.

Just remove any mention of failover from the primary configuration,
shut down the secondary, restart the primary, remove any IP helpers
pointing to the secondary.

And of course, goes without saying, do this in a maintenance window.

Steve
_______________________________________________
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