Curious behaviour with expired/abandoned leases not being given out

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Curious behaviour with expired/abandoned leases not being given out

Christopher Causer

Hi DHCP Users list,

 

May I please have some help understanding what is going on here? I have a pool that by some accounts is not full and in others it is and I don’t understand why.

 

The logs indicate that it is pushing close to the limits of free addresses when balancing

2020-03-10T10:53:19+00:00 $PRIMARY      dhcpd[2147]: balanced pool 55dccc4d51e0 10.20.200.0/22  total 1008  free 2  backup 2  lts 0  max-misbal 1

2020-03-10T10:53:20+00:00 $SECONDARY dhcpd[3683]: balanced pool 555eee5eb1e0 10.20.200.0/22  total 1008  free 2  backup 2  lts 0  max-misbal 1

 

And this is confirmed when some people try to get leases

2020-03-10T10:54:22+00:00 $PRIMARY      dhcpd[3683]: DHCPDISCOVER from $MAC via 10.20.203.254: peer holds all free leases

2020-03-10T10:54:22+00:00 $SECONDARY dhcpd[2147]: DHCPDISCOVER from $MAC via 10.20.203.254: peer holds all free leases

 

However we run dhcpd-pools. The subnet is 43% utilized, but 100% “touch utilized”:

$ dhcpd-pools

Ranges:

shared net name     first ip           last ip            max   cur    percent  touch   t+c  t+c perc     bu  bu perc

[snip]

All networks        10.20.200.1      - 10.20.203.240     1008   434     43.056    573  1007    99.901      1    0.099

 

What is happening here? I can see the touched percentage being high, but as I understand it that should not be denying any leases being given out. According to the dhcpd-pools man page, touched IPs are “    

IP’s which appear in the lease file, but who’s leases have expired. A touched IP is either expired or abandoned.” We have many subnets and there are only two with a touch percentage of ~100% and these are both subnets experiencing issues.

 

I’ve set the abandon-lease-time to 1800. Running ping against the subnet, sources from the DHCP server, I do not get anywhere close to 50% responses.

 

Any help gratefully received. Redacted config below. The leases file is too large and contains sensitive data that I don’t think my employer would be willing to hand out unfortunately. I am happy to redact and share relevant snippets if required though.

 

# /etc/dhcp/dhcpd.confcd

-------------------------------------------------->8-------------

ddns-updates off;

ddns-update-style none;

authoritative;

log-facility local7;

local-address $IP;

server-identifier $IP;

 

key EXKEY {

    [snip]

};

 

omapi-port 7911;

omapi-key EXKEY;

 

include "/etc/dhcp/options.conf";

 

include "/etc/dhcp/failover.conf";

 

include "/etc/dhcp/nets.conf";

-------------------------------------------------->8-------------

 

 

 

## /etc/dhcp/options.conf

-------------------------------------------------->8-------------

option option-150 code 150 = array of ip-address;

-------------------------------------------------->8-------------

 

 

 

## /etc/dhcp/failover.conf

-------------------------------------------------->8-------------

failover peer " dhcp" {

    primary;

    address $THIS_ADDRESS;

    port 847;

    peer address $PEER_ADDRESS;

    peer port 848;

    max-response-delay 5;

    max-unacked-updates 10;

    load balance max seconds 3;

    # ONLY ON PRIMARY

    mclt 1800;

split 128;

# /ONLY ON PRIMARY

   

}

-------------------------------------------------->8-------------

 

 

 

## /etc/dhcp/nets.conf

# Very long, so snipped considerably

-------------------------------------------------->8-------------

abandon-lease-time 1800;

default-lease-time 900;

max-lease-time 900;

ping-check false;

one-lease-per-client true;

boot-unknown-clients true;

option domain-name-servers [snip];

option domain-name "[snip]";

option time-servers uk.pool.ntp.org;

 

subnet 10.20.200.0 netmask 255.255.252.0 {

    option routers 10.20.203.254;                                                                                                                                                                                                                                              

    option subnet-mask 255.255.252.0;                                                                                                                                                                                                                                          

                                                                                                                                                                                                                                                                               

    pool {                                                                                                                                                                                                                                                                     

            deny dynamic bootp clients;                                                                                                                                                                                                                                        

            failover peer "dhcp";                                                                                                                                                                                                                                      

            range 10.20.200.1 10.20.203.240;                                                                                                                                                                                                                                   

    }                                                                                                                                                                                                                                                                          

}        

-------------------------------------------------->8-------------

 

 


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Curious behaviour with expired/abandoned leases not being given out

perl-list
I've seen situations where one client can continuously DHCPDECLINE every address that is allocated essentially marking entire pools abandoned.  It goes like this:

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPDECLINE

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPDECLINE

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPDECLINE

over and over and over again at a very rapid pace.  Check your logs for this type of behavior and remove the offending device from the network if found.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Curious behaviour with expired/abandoned leases not being given out

Bob Harold

On Tue, Mar 10, 2020 at 10:06 AM perl-list <[hidden email]> wrote:
I've seen situations where one client can continuously DHCPDECLINE every address that is allocated essentially marking entire pools abandoned.  It goes like this:

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPDECLINE

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPDECLINE

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPDECLINE

over and over and over again at a very rapid pace.  Check your logs for this type of behavior and remove the offending device from the network if found.


I have also seen this, and if memory serves me, the lease file will show 'state' as "5" for the declined IP's.

-- 
Bob Harold
 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: Curious behaviour with expired/abandoned leases not being given out

Christopher Causer
In reply to this post by perl-list
On Tue, Mar 10, 2020 at 10:06:35AM -0400, perl-list wrote:
> I've seen situations where one client can continuously DHCPDECLINE
> every address that is allocated essentially marking entire pools
> abandoned.  It goes like this:

Interesting thought. There are indeed many DHCPDECLINEs in the
logs. However, this isn't limited to one client; there are 349
distinct MACs in total in the last hour. The only connection is
they're almost exclusively Apple devices (MBP, iPhone etc). These
stations usually DHCPREQUEST their second offer.

A colleague suggested that something like Bonjour Sleep Proxy may be
the underlying cause. I was doubtful given that would affect all
devices doing an arp rather than Apple devices. However, after turning
on client isolation on one of the subnets we are no longer seeing
DHCPDECLINEs and the touched percentage is indeed going down for that
subnet.

So in summary thank you for the helpful replies. Although I'm still
not certain as to the underlying cause of the issue, we now have an
easy to implement workaround.

Christopher


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