From dmrz@illinois.edu Mon Mar 14 23:21:51 2016 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-RT-Interface: API References: <56D0F465.5010402@illinois.edu> <56D61663.8050108@illinois.edu> Message-ID: <56E7478A.8050809@illinois.edu> content-type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by bugs.isc.org (Postfix) with ESMTP id 8849E71B5A8 for ; Mon, 14 Mar 2016 23:21:50 +0000 (UTC) Received: from golbez.ci.uiuc.edu (golbez.ci.uiuc.edu [192.17.25.102]) by mx.pao1.isc.org (Postfix) with ESMTP id E02CC3493A5 for ; Mon, 14 Mar 2016 23:21:48 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by golbez.ci.uiuc.edu (Postfix) with ESMTP id DBA17220C4A for ; Mon, 14 Mar 2016 18:21:47 -0500 (CDT) Delivered-To: dhcp-bugs@bugs.isc.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 Subject: Re: [ISC-Bugs #41815] issues reclaiming abandoned leases Return-Path: X-Original-To: dhcp-bugs@bugs.isc.org Date: Mon, 14 Mar 2016 18:21:46 -0500 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: dhcp-bugs@isc.org Content-Transfer-Encoding: 8bit From: "David Zych" RT-Message-ID: Content-Length: 2223 On 03/14/2016 12:46 PM, Shawn Routhier via RT wrote: > Part of the problem is the nature > of the testing we both did. In the test there is only a very small number > of leases and the are all abandoned. I'm not convinced that the nature of the testing is a problem; why does the small number of leases make a difference? Imagine a pool of 1,000 addresses, of which 996 are currently active leases and the remaining 4 are occupied by squatters. Now a new client shows up and tries to obtain a lease. AFAICT the bug in question will cause at least one of those abandoned leases to be inappropriately DHCPOFFERed without a ping-check after several retries (I think probably on the new client's 5th DHCPDISCOVER attempt if using a single server, or sooner if using failover). Note: obviously the pool has to be full (counting active + abandoned) in order for this bug to manifest, but that follows trivially from the fact that it's a bug in the behavior of reclaiming abandoned leases, and reclaiming abandoned leases should* only occur when the pool is full. [* the other bug in this same ticket (abandoned leases inappropriately freed after 2 minutes) notwithstanding] > In this case the serve has two bad > options - don't hand out a lease or try to reuse an abandoned lease - which > is worse is somewhat dependent on the rest of your set up. In this case, the lease was marked abandoned less than a minute (or however long it is) ago, so we know the squatter was present at that time; the question is, is the squatter still present now? If so, then no correct behavior by the DHCP server can possibly result in handing out the lease. So the difference is, would we rather risk bombarding the squatter with many pings (if we receive many DHCPDISCOVERs), or would we rather risk maintaining an abandoned lease for up to 1 extra minute (?) longer than necessary after the squatter has in reality gone away? In light of the fact that ISC has in the past deemed it necessary to write ping-limiting code in the first place, I would tend to lean toward that option, but either option would be much better than the present behavior of "try to reuse an abandoned lease without ping-checking it first". Thanks, David