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: dont-use-fsync real world impact (Bob Harold)
2. Re: dont-use-fsync real world impact (Simon Hobson)
3. Re: stuck up record in DNS (ivan nepryakhin)
4. Re: DHCP leases issue (Surya Teja)
----------------------------------------------------------------------
Message: 1
Date: Mon, 9 Sep 2019 17:03:53 -0400
From: Bob Harold <rharo...@umich.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dont-use-fsync real world impact
Message-ID:
<CA+nkc8Af4+b7DVkMnnR4=o0-ss7ue6-kagqmzt6jf7ehyvs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sat, Sep 7, 2019 at 6:19 PM Simon Hobson <dh...@thehobsons.co.uk> wrote:
> 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.
>
If you have a failover pair, then changes to one server get sent to the
other server, and I expect that to be immediate (but don't know that for
sure), so if one server fails, you would only lose a few seconds or less.
In that case would running without fsync be reasonable?
--
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190909/ab7cacd3/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 10 Sep 2019 10:35:33 +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: <f46b49be-a8cc-456a-99a0-c133c65dc...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Bob Harold <rharo...@umich.edu> wrote:
> If you have a failover pair, then changes to one server get sent to the other
> server, and I expect that to be immediate (but don't know that for sure), so
> if one server fails, you would only lose a few seconds or less. In that case
> would running without fsync be reasonable?
AIUI failover updates are "instant" but there's a config option to batch them.
Similarly IIRC there's now a config option to batch lease file updates/fsyncs ?
Both these config options being there to allow adjustment of the
performance/security tradeoff.
But you do raise a good point, with failover you have a near instantly updated
backup of the leases. Apart from the obvious, there have been some interesting
suggestions in the past for how that could be used.
------------------------------
Message: 3
Date: Tue, 10 Sep 2019 13:51:43 +0300
From: ivan nepryakhin <nepryakhin.1...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>,
dh...@thehobsons.co.uk, koko...@speechpro.com
Subject: Re: stuck up record in DNS
Message-ID:
<CAK=DxUxvwCRCq97=nG2H=YuYNJFN1sk6iY=zghbqiwzkanz...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Tom !
I didn't can answer earlier
> It's normal operation, as I explained in my reply to the same question on
11th, see https://lists.isc.org/pipermail/dhcp-users/2019-August/021730.html
Sorry for repeat but Unfortunately i didn't get mail in my work mail and
repeat question via private mail.
> Where you have a host entry, the lease does NOT go through the normal
lifecycle - and would not normally appear in the leases file.
But host about im write NOT not declare in dhcpd.conf
--------------------START INFO ABOUT ISSUE
HOST----------------------------------------------
lease 10.10.10.12 {
starts 5 2019/08/09 11:00:47;
ends 5 2019/08/09 12:00:47;
tstp 5 2019/08/09 12:00:47;
cltt 5 2019/08/09 11:00:47;
binding state free;
hardware ethernet 18:10:2b:12:db:12;
uid "\001\010\000'\216G\220";
}
cuted from the file /etc/named/tsc/tsc.zone:
$TTL 1800 ; 30 minutes
host12-c12-1 A 10.10.10.12
TXT "00ffa9c88e143752544ac44exxxxxxxxxx"
------------------END INFO ABOUT ISSUE
HOST----------------------------------------------------
------------------START CONFIGURATION
FILE-----------------------------------------------------
## DDNS related configuration
ddns-update-style interim;
ddns-rev-domainname "in-addr.arpa.";
ddns-domainname "tsc.";
update-static-leases on;
group {
option routers 10.10.10.1;
ddns-hostname = host-decl-name;
update-optimization false;
update-conflict-detection false;
# example host
host host12 {
hardware ethernet 18:31:BF:xx:xx:xx;
fixed-address 10.10.10.111;
}
}
------------------END CONFIGURATION
FILE-----------------------------------------------------
My question about - Why host can stay in DNS without record in config file
and without manual doing it record in DNS.
On Thu, 22 Aug 2019 at 23:00, Simon Hobson <dh...@thehobsons.co.uk> wrote:
> ivan nepryakhin <nepryakhin.1...@gmail.com> wrote:
>
> > I'm encountered with a strange issue:
>
> It's normal operation, as I explained in my reply to the same question on
> 11th, see
> https://lists.isc.org/pipermail/dhcp-users/2019-August/021730.html
>
> _______________________________________________
> 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/20190910/5c4c5bc6/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 10 Sep 2019 16:25:19 +0530
From: Surya Teja <suryateja...@gmail.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP leases issue
Message-ID:
<CA+0Ac3yRuT5_305ooRYsnC=Huyfgf5T=vhsyfkmbnaiwd1v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Simon,
Thanks for reply, Yes I can increase the scope range but i have clients
like 100-120 per floor(per subnet) I don't think it would be good idea to
increase its scope size to some /8 subnet and over come this issues
Let me explain the scenario. If the client moved from subnet A and subnet B
we may not sure that client returning to previous subnet for that whole
working day or not.
So the IP assigned to that client in subnetA is of no use for period of
duration. This happens to multiple IP's
I want to set the config in such a way that before DHCP granting the lease
can it check the existing lease file with that mac address and free the
previous ones if it has from other subnets or scope.
As suggested by Thomas I have added the statement *one-lease-per-client
true to config *and till now I didn't see any issues but as it is not sure
I am still observing the cases.
On Sun, Sep 8, 2019 at 4:00 AM Simon Hobson <dh...@thehobsons.co.uk> wrote:
> Surya Teja <suryateja...@gmail.com> wrote:
>
> > 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?
>
> You CANNOT do that without violating the DHCP specification. Note that the
> client is within it's rights to store all the leases it has, and on
> returning to the previous subnet, continue using the lease it still has for
> that subnet. So if the server has handed the address out to another client
> in the meantime, you can have an address clash.
> So short version "do NOT do that" !
>
> > The first IP is getting into free state after completing its 1 hour
> lease duration till that time it is active mode only.
>
> That is correct operation.
>
> The correct response to "I don't have enough addresses" is to increase the
> size of the address pool(s). It's a balancing act - on the one hand longer
> leases give you stability and more time to respond to DHCP server issues;
> while on the other hand, shorter leases suit highly mobile users (high
> churn rate). For short leases, even 60 minutes is (IMO) getting rather
> short - you only need one hiccup with your DHCP service and your users have
> between 30 and 60 minutes before they fall off the network and call your
> helpdesk.
>
> If you are finding that you run out of leases then it suggests you have
> your network design wrong. There is LOTS of address space in the RFC1918
> blocks, and you are certainly not constrained to use /24 subnets in the
> 192.168.n.n allocation. Use 10.n.n.n/8 and you have 16 million addresses to
> play with !
>
>
> _______________________________________________
> 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/20190910/39dc903d/attachment.html>
------------------------------
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 8
******************************************
