Failover host stops releasing IP's if the peer is down.

[p0wn3rs]

Hello,

we have different DHCP clusters and sometimes happens for a system to be
down for a long time (the location doesn't grant us immediate physical
access and the hw doesn't support WOL).
Whenever this happens the main host stops releasing IP's...

Dec  9 10:39:36 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d6:ff via
br1: not responding (recovering)
Dec  9 10:39:37 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d7:29 via
br1: not responding (recovering)
Dec  9 10:39:39 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d6:ff via
br1: not responding (recovering)
Dec  9 10:39:41 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d7:29 via
br1: not responding (recovering)
Dec  9 10:39:43 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d6:ff via
br1: not responding (recovering)

Configuration :

cat /etc/dhcpd.conf

ddns-update-style none;

deny bootp;

authoritative;

option wpad code 252 = text;

failover peer "CLUSTER" {

     primary;

     mclt 600;

     split 128;

     address 192.168.177.1;

     peer address 192.168.177.2;

     port 519;

     peer port 519;

     max-response-delay 30;

     max-unacked-updates 10;

     load balance max seconds 3;

}

shared-network SERVERS {

     interface br1;

     server-identifier 192.168.18.1;

     subnet 192.168.18.0 netmask 255.255.255.0 {

         pool {

             failover peer "CLUSTER";

             deny dynamic bootp clients;

             range 192.168.18.100 192.168.18.200;

         }

         default-lease-time 3600;

         max-lease-time 7200;

         option subnet-mask 255.255.255.0;

         option domain-name "mydomain.com";

         option routers 192.168.18.1;

         option wpad "http://192.168.18.1/proxy.pac";

         option domain-name-servers 192.168.18.1;

     }

}



lease-file-name "/var/lib/dhcp/dhcpd.leases";

cat /var/lib/dhcp/dhcpd.leases
# The format of this file is documented in the dhcpd.leases(5) manual page.
# This lease file was written by isc-dhcp-4.2.5-P1


failover peer "CLUSTER" state {
   my state recover at 1 2019/12/09 08:52:57;
   partner state unknown-state at 1 2019/12/09 08:52:57;
}

failover peer "CLUSTER" state {
   my state recover at 1 2019/12/09 08:52:57;
   partner state unknown-state at 1 2019/12/09 08:52:57;
}
server-duid "\000\001\000\001%\200\307\351\200\306\312\001\015\354";


failover peer "CLUSTER" state {
   my state recover at 1 2019/12/09 08:52:57;
   partner state unknown-state at 1 2019/12/09 08:52:57;
}

So, the partner state is in "unknown-state" because of course is down,
but shouldn't the host be releasing IP's after some time?
How can we solve this problem?
thanks,
Robert.

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

[Simon Hobson]

p0wn3rs <[hidden email]> wrote:

>Hello,
>
>we have different DHCP clusters and sometimes happens for a system to
>be
>down for a long time (the location doesn't grant us immediate physical
>access and the hw doesn't support WOL).
>Whenever this happens the main host stops releasing IP's...
>
>Dec  9 10:39:36 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d6:ff via
>br1: not responding (recovering)
>Dec  9 10:39:37 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d7:29 via
>br1: not responding (recovering)

I think you have your terminology wrong. It is not offering a lease, "release" in DHCP terminology has a very different meaning.

What happens if you put the surviving server into partner-down state ? It should then take over the whole pool and act like a single server. When the peer comes back up, they should automatically recover.

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

[p0wn3rs]

Hello,
yes, now it's getting the IP's.
Is there a way to "timeout" the surviving server and set it on
partner-down automatically?
thanks.

On 12/9/19 2:04 PM, Simon Hobson wrote:

> p0wn3rs <[hidden email]> wrote:
>> Hello,
>>
>> we have different DHCP clusters and sometimes happens for a system to
>> be
>> down for a long time (the location doesn't grant us immediate physical
>> access and the hw doesn't support WOL).
>> Whenever this happens the main host stops releasing IP's...
>>
>> Dec  9 10:39:36 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d6:ff via
>> br1: not responding (recovering)
>> Dec  9 10:39:37 fw-01 dhcpd: DHCPDISCOVER from 00:a0:ba:0f:d7:29 via
>> br1: not responding (recovering)
> I think you have your terminology wrong. It is not offering a lease, "release" in DHCP terminology has a very different meaning.
>
> What happens if you put the surviving server into partner-down state ? It should then take over the whole pool and act like a single server. When the peer comes back up, they should automatically recover.
>
> _______________________________________________
> 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

[Niall O'Reilly]

On 9 Dec 2019, at 13:39, p0wn3rs wrote:

> Is there a way to "timeout" the surviving server and set it on
> partner-down automatically?

Sure. See https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf (or
the
corresponding documentation for the version of interest to you) and in
particular
the warning, "Think very carefully before enabling this feature."

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

[Simon Hobson]

Niall O'Reilly <[hidden email]> wrote:
>

> Sure. See https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf (or the
> corresponding documentation for the version of interest to you) and in particular
> the warning, "Think very carefully before enabling this feature."

Specifically, the section on "The auto-partner-down statement".
Just to expand in case the OP doesn't get it - IMO the warning might not be recognised by some users. There is no guarantee that a loss of communications between peers means that one of them can no longer serve clients. Having two isolated servers handling the same address range is highly liable to create some very "interesting" problems as they start to hand out the same addresses to different clients and other such bad behaviour. This is why this option is turned off by default and did not exist until fairly recently.

Turn it on if you wish, but be prepared for weird behaviour under some fault conditions. Personally I don't think this is a sane option to turn on unless both servers are co-located and both connected to ports on the same switch.

An alternative is to simply put monitoring in place (there are many tools to do this) and alert your duty admins should a server go offline or a server go into comms interrupted state. They can then apply some sanity checks and manually put the active server into partner-down state.


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