Send dhcp-users mailing list submissions to dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/dhcp-users or, via email, send a message with subject or body 'help' to dhcp-users-requ...@lists.isc.org You can reach the person managing the list at dhcp-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcp-users digest..." Today's Topics: 1. Re: DHCP leases issue (Thomas Markwalder) 2. dont-use-fsync real world impact (Jure Sah) 3. Re: dont-use-fsync real world impact (Andrew Bell) 4. Re: dont-use-fsync real world impact (Simon Hobson) ---------------------------------------------------------------------- Message: 1 Date: Sat, 7 Sep 2019 09:19:19 -0400 From: Thomas Markwalder <tm...@isc.org> To: dhcp-users@lists.isc.org Subject: Re: DHCP leases issue Message-ID: <0281d2d3-848d-0c3e-482d-7d30deb7d...@isc.org> Content-Type: text/plain; charset="utf-8"; Format="flowed" If you're clients are roaming between networks and are not releasing leases you may wish to use this flag: The /one-lease-per-client/ statement *one-lease-per-client* /flag/*;* If this flag is enabled, whenever a client sends a DHCPREQUEST for a particular lease, the server will automatically free any other leases the client holds. This presumes that when the client sends a DHCPREQUEST, it has forgotten any lease not mentioned in the DHCPREQUEST - i.e., the client has only a single network interface /and/ it does not remember leases it?s holding on networks to which it is not currently attached. Neither of these assumptions are guaranteed or provable, so we urge caution in the use of this statement. On 9/6/19 11:47 PM, Surya Teja wrote: > Hi Bill, > > Thanks for reply as suggested i have increased lease time to one hour > and I observerd one more scenario when the client moves from one > subnet to another subnet ( lease time say 1hr). The client got IP from > the second subnet scope but the previous IP in the 1st subnet is still > in hold and in the lease file. It still recorded an active entry. How > can the dhcp server reclaims those unused IP's? Do we have any > configuration statement making dhcp to cross check all the active IP's > of that scope before saying no free leases. > The first IP is getting into free state after completing its 1 hour > lease duration till that time it is active mode only. > > Thanks in?advance. > > On Sat, 7 Sep 2019, 00:33 Bill Shirley, > <b...@c3po.polymerindustries.biz > <mailto:b...@c3po.polymerindustries.biz>> wrote: > > Note: two minutes (120 seconds) is a very short lease time. > > Are you sure you're looking at the correct lease file?? Your grep > says you have *no** > **leases* on 192.168.3.x. > > Your log entries via looks strange.? I would think it should > contain the interface name: > DHCPDISCOVER from 40:4e:36:d2:bf:9d via wifi > DHCPDISCOVER from b4:18:d1:69:02:f9 (Bobs-iPhone) via wifi > > Bill > > On 9/6/2019 6:25 AM, Surya Teja wrote: >> Hi >> I have configured the dhcp on my local?environment with the >> configuration as >> ================================= >> subnet 192.168.3.0 netmask 255.255.255.0 { >> ? ? ? ? pool { >> ? ? ? ? ? ? ? ? range 192.168.3.3 192.168.3.143; >> ? ? ? ? } >> ? ? ? ? ? ? ? ? default-lease-time 120; >> ? ? ? ? ? ? ? ? max-lease-time 120; >> ? ? ? ? ? ? ? ? option domain-name "example.com >> <http://example.com>"; >> ? ? ? ? ? ? ? ? option routers 192.168.3.1; >> ? ? ? ? ? ? ? ? option subnet-mask 255.255.255.0; >> ? ? ? ? } >> But no client is able to get the IP and in the logs I can see: >> DHCPDISCOVER from 84:EF:18:6A:89:DE via 192.168.3.11 >> <http://192.168.3.11>: network 192.168.3.0/24 >> <http://192.168.3.0/24>:*no free leases* >> DHCPDISCOVER from 00:FF:4A:81:D5:A5 via 192.168.3.16 >> <http://192.168.3.16>: network 192.168.3.0/24 >> <http://192.168.3.0/24>: *no free leases* >> But it is not possible and none of the client get the lease from >> the specified network. I cross checked in the lease file also >> [root@dhcpserver]# cat dhcpd.leases | grep 192.168.3 -A 10 -B 10 >> [root@dhcpserver]# >> It doesn't shows any entry >> >> Any help is appreciated thanks in advance >> >> _______________________________________________ >> dhcp-users mailing list >> dhcp-users@lists.isc.org <mailto:dhcp-users@lists.isc.org> >> https://lists.isc.org/mailman/listinfo/dhcp-users > _______________________________________________ > dhcp-users mailing list > dhcp-users@lists.isc.org <mailto:dhcp-users@lists.isc.org> > https://lists.isc.org/mailman/listinfo/dhcp-users > > > _______________________________________________ > dhcp-users mailing list > dhcp-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20190907/623d8dda/attachment-0001.html> ------------------------------ Message: 2 Date: Sat, 7 Sep 2019 20:17:42 +0200 From: Jure Sah <e...@juresah.si> To: dhcp-users@lists.isc.org Subject: dont-use-fsync real world impact Message-ID: <c366ee3c-3dd7-341d-8526-4ebcb1c10...@juresah.si> Content-Type: text/plain; charset=iso-8859-2 Hi, The documentation clearly states that using the dont-use-fsync option is not recommended. I am wondering what is the realistic impact of this? As I understand the kernel commits dirty pages to disk every 30 seconds by default, and this is configurable. Wouldn't this mean that at worst 30 seconds worth of leases are lost? The leases file is in most cases relatively tiny (under 1 MB), and could easily fit in system storage cache. However the fact that it gets fsynced on every commit means that the performance of the DHCP server is capped at whatever the performance of the physical storage is. While fast storage options exist, this doesn't make the DHCP server future-proof as a solution, which is a problem. >From the past correspondence from the mailing list archive I surmise that people usually work around this by using hardware cache that does not obey fsync, which simply offloads the problem from the kernel to the cache controller and only superficially solves the problem. It however hints towards the view that perhaps not using fsync is not all that bad, if we are talking about a typical professionally hosted server. LP, Jure ------------------------------ Message: 3 Date: Sat, 7 Sep 2019 15:16:13 -0400 From: Andrew Bell <and...@poscomp.ca> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: dont-use-fsync real world impact Message-ID: <CAMcY7=jzcw1fqt8nqiahs_lmziatp4j6byk0m5xg2qf0z5u...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" You made me curious, so I just checked my lease database. 16.7 MB, 57,5712 entries currently. On Sat, Sep 7, 2019 at 2:17 PM Jure Sah <e...@juresah.si> wrote: > Hi, > > The documentation clearly states that using the dont-use-fsync option is > not recommended. > > I am wondering what is the realistic impact of this? As I understand the > kernel commits dirty pages to disk every 30 seconds by default, and this > is configurable. Wouldn't this mean that at worst 30 seconds worth of > leases are lost? > > The leases file is in most cases relatively tiny (under 1 MB), and could > easily fit in system storage cache. However the fact that it gets > fsynced on every commit means that the performance of the DHCP server is > capped at whatever the performance of the physical storage is. While > fast storage options exist, this doesn't make the DHCP server > future-proof as a solution, which is a problem. > > From the past correspondence from the mailing list archive I surmise > that people usually work around this by using hardware cache that does > not obey fsync, which simply offloads the problem from the kernel to the > cache controller and only superficially solves the problem. It however > hints towards the view that perhaps not using fsync is not all that bad, > if we are talking about a typical professionally hosted server. > > LP, > Jure > _______________________________________________ > dhcp-users mailing list > dhcp-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20190907/92f87af5/attachment-0001.html> ------------------------------ Message: 4 Date: Sat, 7 Sep 2019 23:19:02 +0100 From: Simon Hobson <dh...@thehobsons.co.uk> To: Users of ISC DHCP <dhcp-users@lists.isc.org> Subject: Re: dont-use-fsync real world impact Message-ID: <520c2dbc-ce52-476a-b085-fc84524f9...@thehobsons.co.uk> Content-Type: text/plain; charset=us-ascii Jure Sah <e...@juresah.si> wrote: > The documentation clearly states that using the dont-use-fsync option is > not recommended. > > I am wondering what is the realistic impact of this? As I understand the > kernel commits dirty pages to disk every 30 seconds by default, and this > is configurable. Wouldn't this mean that at worst 30 seconds worth of > leases are lost? Yes, but that could be a rather serious loss of data for some operators. As always, there's no "one size fits all" answer, different operators will have different ideas on this. Indeed, AIUI (from several years ago at least) the DHCP service in Windows Server massively outperformed the ISC DHCp server in benchmarks using out of the box settings. The reason for this was that the MS server did NOT fsync it's leases database and thus is vulnerable to exactly the issue you mention - also making non-compliant with the relevant RFC. However, in their defence, they have "sort of" moved that security aspect to clients by making the clients very sticky about their leases - more so than other clients in my observations. That doesn't fully prevent the problem of the server missing knowledge of leases it's granted. > The leases file is in most cases relatively tiny (under 1 MB) That's probably a generalisation too far. Mine (at home) is only 20k, but as Andrew Bell has already pointed out, some people do have large lease files. > From the past correspondence from the mailing list archive I surmise > that people usually work around this by using hardware cache that does > not obey fsync, which simply offloads the problem from the kernel to the > cache controller and only superficially solves the problem. Yes, but no. Yes it offloads the problem, no it's not just a superficial fix. A "proper" hardware cache will be battery backed and can survive a crash or power failure of the host. So if we assume we're talking about the hardware cache in a disk controller (eg a RAID controller) then if the power goes off without the chance of an orderly shutdown, then the battery backed cache will hold the updates until the power comes back on again - at which point it will push the updates out to the disk(s). There are other sorts of cache hardware. In the distant past I recall seeing (and drooling over !) a "magic box" that comprised a stack of RAM, some disks, a battery, and a controller. To the host it presented as a standard wide SCSI device (that dates it), while internally it was a big RAM disk. In the event of power failure, the battery would run the system long enough to write everything to disk. In both cases (and others), under normal conditions it's safe to assume that if the "disk" comes back and says "yes that's written", then it's either been written or has been saved into battery backed cache that will survive problems such as host crashes or power failures. If the cache/disk subsystem fails in that promise, then that's really little different to having a normal disk fail and lose all your data. ------------------------------ Subject: Digest Footer _______________________________________________ dhcp-users mailing list dhcp-users@lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users ------------------------------ End of dhcp-users Digest, Vol 131, Issue 6 ******************************************