peer holds all free leases - ISC DHCPd 4.3.1

[Prabir Kr Sarkar]

Hi,
   We are running DHCP Server, ISC DHCPd version in a cluster mode. 4.3.1. For a few days now we are getting the following. Can this possibly be due to a failure in syncing of the lease pool information between the DHCP cluster nodes? If so, what is the workaround?

Note: I have masked the IP, MAC, port, FQDN information for privacy/security reasons.

*Excerpts from "/etc/opt/csw/dhcpd.conf"*

*Cluster node config details >*

failover peer "failover" {

  secondary;
  address 15x.xxx.xxx.5;
  port x47;
  peer address 15x.xxx.xxx.6;
  peer port x47;
  max-response-delay 60;
  max-unacked-updates 10;
  load balance max seconds 3;
  mclt 3600;
#  split 128;
}


*Relevant portion of the subnet's lease >*

subnet 10.xxx.24.0 netmask 255.255.254.0 {
        ddns-updates on;
        pool {
                range 10.xxx.24.101 10.xxx.25.254;
                failover peer "failover";
                }
        option routers 10.xxx.24.1;
        option domain-name-servers xxx.xxx.xxx.xxx;
        option domain-name "dhcp.xxx.xxx.com";
        option ntp-servers 157.xxx.xxx.5 , 157.xxx.xxx.6;
        option netbios-name-servers 157.xxx.xxx.xx;
        }


Mar 29 18:20:14 dns1.xxx.xxx.com dhcpd: [ID 702911 local1.error]
DHCPDISCOVER from 5c:xx:xx:xx:7c:72 via 10.xxx.24.3: *peer holds all free leases*

Mar 29 18:20:14 dns1.xxx.xxx.com dhcpd: [ID 702911 local1.error]
DHCPDISCOVER from 5c:xx:xx:xx:7c:72 via 10.xxx.24.2: *peer holds all free leases*


Mar 29 18:20:14 dns2.xxx.xxx.com dhcpd: [ID 702911 local1.error]
DHCPDISCOVER from  5c:xx:xx:xx:7c:72 via 10.xxx.24.2: *peer holds all free leases*

Mar 29 18:20:14 dns2.xxx.xxx.com dhcpd: [ID 702911 local1.error]
DHCPDISCOVER from 5c:xx:xx:xx:7c:72 via 10.xxx.24.3:* peer holds all free leases*

--

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

[Simon Hobson]

Prabir Kr Sarkar <[hidden email]> wrote:

> For a few days now we are getting the following. Can this possibly be due to a failure in syncing of the lease pool information between the DHCP cluster nodes?


> Mar 29 18:20:14 dns1.xxx.xxx.com dhcpd: [ID 702911 local1.error]
> DHCPDISCOVER from 5c:xx:xx:xx:7c:72 via 10.xxx.24.3: *peer holds all free leases*

Does the other server respond ? Does it have any free leases to hand out ?
But more importantly, what is logged in regarding failover and pool balancing ? You may need to go back to when balancing stopped and see what each peers said about failover status.



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

[John Wobus]

On Mar 29, 2016, at 10:37 AM, Prabir Kr Sarkar <[hidden email]> wrote:
> We are running DHCP Server, ISC DHCPd version in a cluster mode. 4.3.1. For a few days now we are getting the following. Can this possibly be due to a failure in syncing of the lease pool information between the DHCP cluster nodes? If so, what is the workaround?

Regarding the redundant connection, it is tcp and netstat can tell you if the connections
were made, which proves a lot, that firewalls, access lists, etc. are letting the traffic through.
In our setup, we get logged lines with the phrases “balancing pool” and “balanced pool” that
appear to indicate redundancy info being swapped.

FYI, folks are sometimes led astray interpreting the message “peer holds all free leases”.
With that message you need to look at any configuration element that might disqualify the client
from getting an address.

The message means this server has no address that that the client qualifies for.
This could be because a pool is totally full or because though the pool
has one or more free leases, all the free leases are in the hands of the other server.

But the same message is also given for any other mechanism that you’ve configured that makes the
address or pool to be ineligible for the client, e.g. classes, known/unknown, etc.  Even if the
configuration has no pool that would ever serve the client, and even if both servers are configured
in that way.

A more verbose but possibly clearer message might be “this server has no lease for which that
client qualifies, but for all this server can tell, our peer server might possibly have one”.

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