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
******************************************

Reply via email to