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: Configuring option 82 (Bob Harold)
2. Re: DHCP restart with bulk lease data (Simon Hobson)
3. Re: dont-use-fsync real world impact (Simon Hobson)
4. Re: Override dynamic lease with static reservation (Simon Hobson)
5. Re: Configuring option 82 (Simon Hobson)
6. Re: dont-use-fsync real world impact (Jure Sah)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 Sep 2019 11:16:30 -0400
From: Bob Harold <rharo...@umich.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Configuring option 82
Message-ID:
<CA+nkc8Aez=H2SUa-XbnwoRmBpOm_azPL+S=h4nse7yvvgi5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Fri, Sep 27, 2019 at 10:21 AM Sten Carlsen <st...@s-carlsen.dk> wrote:
>
>
> On 27/09/2019 15.59, Surya Teja wrote:
>
> Hi Bill,
> Do you have 40,000 clients?
> Yes some times the dhcp client traffic reaches nearly 40-50k in my
> environment.
> What is you goal here?
> I want to avoid the untrusted dhcp clients to request the server and fill
> up the leases, So I went through internet and found that option 82 can be a
> similar functionality.
> Link I checked for:
> https://kb.zyxel.com/KB/searchArticle!gwsViewDetail.action?articleOid=009391&lang=EN
>
>
> This example has a few problems:
> It defines classes inside the subnet, this is not a good idea. Keep
> declarations global.
> It does not prevent unknown-clients from getting an IP from any of the
> pools, it is missing the deny unknown-clients; statement.
> allow members of "VLAN10"; denies other classes but
> does not deny unknown-clients as you seem to want.
>
It has been my experience that "allow members of VLAN10" implies "deny all
else".
And using "known-clients" or "unknown-clients" in the DHCP config is a bad
idea - if a MAC address is given a DHCP Reserved entry in one subnet, that
suddenly changes its 'known" status on other subnets causing it to get or
lose access to those subnets. Rarely is there a real need for
"known-clients" or "unknown-clients".
--
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20190927/9391272b/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 27 Sep 2019 18:21:17 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP restart with bulk lease data
Message-ID: <3220c72e-f8af-41a7-8e24-63cfbe399...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Surya Teja <suryateja...@gmail.com> wrote:
>
> Hi Simon Thanks for reply,
> Periodically, default is every hour, the server will write out a fresh
> leases file from it's internal structures --->
> I have a doubt when the server write out a fresh leases file from it's
> internal structures will the dhcpd service be in off state at this duration?
The question is a little ambiguous.
If you mean, will this happen while the server is stopped, no it won't.
If you mean, does the server stop serving clients while it's doing this, AFAIK
it continues as normal.
>> this file will contain no duplicate entries --->
> Hi I have seen the duplicate entry in my server lease file
> sample snippet:
> ==============
> lease 192.168.2.52 {
> starts 5 2019/09/27 07:21:32;
> ends 5 2019/09/27 08:21:32;
> tstp 5 2019/09/27 08:51:32;
> tsfp 5 2019/09/27 08:21:32;
> cltt 5 2019/09/27 07:21:32;
> binding state active;
> next binding state expired;
> hardware ethernet 70:bb:e9:37:d9:9e;
> uid "\001p\273\3517\331\236";
> set vendor-class-identifier = "android-dhcp-9";
> client-hostname "RedmiNote6Pro";
> }
> lease 192.168.2.52 {
> starts 5 2019/09/27 07:21:32;
> ends 5 2019/09/27 08:21:32;
> tstp 5 2019/09/27 08:51:32;
> tsfp 5 2019/09/27 08:51:32;
> atsfp 5 2019/09/27 08:51:32;
> cltt 5 2019/09/27 07:21:32;
> binding state active;
> next binding state expired;
> hardware ethernet 70:bb:e9:37:d9:9e;
> uid "\001p\273\3517\331\236";
> set vendor-class-identifier = "android-dhcp-9";
> client-hostname "RedmiNote6Pro";
> }
> Yes It has same data, I don't see any issue on client side but want to make
> sure that, Is this acceptable in lease file ?
The lease file will be clean **immediately** after it's been re-written. Once
clients are served, then new records will be appended and there is likely to be
more than one record for some clients.
Looking at the above, are you running failover ? If so, then I suspect one of
the records is from the partner server making an offer to a client at the same
time as this server does.
------------------------------
Message: 3
Date: Fri, 27 Sep 2019 18:46:08 +0100
From: Simon Hobson <si...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: dont-use-fsync real world impact
Message-ID: <c7b80b8b-05cc-491f-bd1f-2a08f019d...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Jure Sah <e...@juresah.si> wrote:
> Well, a typical modern server, especially if it's a dedicated machine
> has at least 64 GB of RAM, of which the OS takes up at most 4 GB,
> leaving a good 60 GB of cache space for that lease file.
You've obviously worked for more generous managers than I have :-(
>>> 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.
>
> See and this is where I see the problem. I understand that this is a
> software mailing list and that this might not exactly be obvious to
> people who deal with things several abstraction layers above the
> hardware... and I also understand that at the end of the day this might
> not matter in the real world. However, if the question is the value of
> fsync and battery-backed disk cache, consider the following:
>
> When a write is executed, it is first built in the write buffer of the
> application, from where it is transfered to the kernel file page memory
> structure in system RAM. When an fsync or dirty page write is executed,
> the kernel pushes the data over to the disk controller which stores it
> in the hardware disk write buffer, and then transfers it to the physical
> media.
>
> If there is a power failiure, and it unluckily occurs before a dirty
> page write or fsync, then the data is still in the system RAM and it
> goes poof and is never committed to the battery backed hardware disk
> write buffer, to be put into the disks on reboot. So exactly what impact
> does the battery have on systems that do not carry out timely fsyncs?
I stink we are talking slightly different combinations of options.
I was talking about using battery backed cache to mitigate the performance
issue of frequent fsyncs. So the steps between application building a new
record and it being "secure" are fast, leaving the slow disk writes protected
by battery backup to the cache.
If we are talking about when the application doesn't do fsyncs, then I agree
with you.
> I've had some discussions on the topic on the other applications mailing
> lists, and it appears that the developers of the software understand
> that the primary purpose of regular fsyncs is to ensure atomic writes,
> rather than to preserve seconds worth of leases. If there is an
> unmitigated power failiure it is understood that there will be some data
> loss, but the fsyncing is there to ensure that the leases database
> remains in a recoverable state (in the case of the leases file, atomic
> writes ensure that the leases file is syntactically correct). They
> understood the performance bottleneck of their application due to fsync,
> but conceded that without an atomic write mechanism by the underlying
> filesystems, there was no real alternative.
It's my understanding that the fsyncs are to ensure that the data has been
committed to permanent storage BEFORE the lease is offered to a client - as
required by the DHCP RFCs. Atomic writes aren't really an issue - I strongly
suspect that the server builds a whole lease file record in the buffer and
passes that in one write operation, and if that's the case, then the only
non-atomic write issue would be if multiple writes were made (without fsync)
such that lease file records cross a disk buffer boundaries.
If a lease file entry were truncated, then I believe the server can deal with
this on startup by discarding the incomplete record.
So yes, ensuring atomic writes is a by-product of using fsyncs - but not (in
this case) the primary reason.
------------------------------
Message: 4
Date: Fri, 27 Sep 2019 18:59:51 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Override dynamic lease with static reservation
Message-ID: <cb45c9ab-b384-41ba-85b5-a80280801...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Marc Haber <mh+dhcp-us...@zugschlus.de> wrote:
> I find it a rather common occurence that a client that currently holds a
> dynamic lease should get a static reservation of a different IP address.
> Thus, a host entry is put into the configuration and the client
> rebooted.
>
> It then asks for the last IP address it knows of, which is the dynamic
> address. The server proceeds to look in its database, says "yup, here is
> the address".
Yes, that's correct.
As an alternative to the host declaration, setting the reserved flag on the
lease will achieve almost the same effect - but still needs OMSHELL or lease
file editing). The address is permanently reserved for the client, but unlike a
host declaration, it goes through the normal lease lifecycle (it can expire,
DNS updates happen properly, etc).
> The usual method is to delete the dynamic address from the database,
> which either involves a rather fragile and often misbehaving omshell
> process where the only "documentation" is half a mailing list thread
> from ten years ago, or shutting down the server and hand-editing the
> database file (which is a service interruption).
>
> Is there a configuration option to tell the server "if there is
> something static for this client, forget everything dynamic you might
> have and NAK the dynami address from the client"?
deny known-clients (or allow unknown-clients) might do what you want.
------------------------------
Message: 5
Date: Fri, 27 Sep 2019 19:15:11 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Configuring option 82
Message-ID: <d94a9960-1d2e-4145-8a8b-c9441965e...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Surya Teja <suryateja...@gmail.com> wrote:
> I just want to make sure that my DHCP server will grant IP from particular
> subnet to the clients which has specified value in
> agent.circuit-id/agent.remote-id suboptions of option 82 from request packets
> (DHCP relay will be adding the option 82 info to request packet)
You do not need to do anything for that to happen - it's just automagic.
The server will automatically match a client to the right subnet according to
either the interface the request comes in on (for local clients) or the Gateway
Interface Address (GI-Addr) set by the relay agent (for remote clients).
So lets say you have two subnets: The server is on the 192.168.1.0/24 subnet,
and the relay agent is listening on the 192.168.2.0/24 subnet (lets say it's IP
is 192.168.2.2). The server receiving a relayed request will find GI-Addr set
to 192.168.2.2 and automatically select a client address from the
192.168.2.0/24 subnet declaration. For the server, all it needs is :
<global stuff>
subnet 192.168.1.0 ... {
}
subnet 192.168.2.0 ... {
<subnet specific options>
range 192.168.2.xx 192.168.2.xx ;
}
That's really all there is to it. If there are no clients connected locally to
the server, then the local subnet (192.168.1.0/24 in this example) can be empty
as above.
------------------------------
Message: 6
Date: Sat, 28 Sep 2019 13:33:50 +0200
From: Jure Sah <e...@juresah.si>
To: dhcp-users@lists.isc.org
Subject: Re: dont-use-fsync real world impact
Message-ID: <5ae81c59-89f8-1ff3-b9c3-dfc636b89...@juresah.si>
Content-Type: text/plain; charset=iso-8859-2
On 27. 09. 19 19:46, Simon Hobson wrote:
> It's my understanding that the fsyncs are to ensure that the data has been
> committed to permanent storage BEFORE the lease is offered to a client - as
> required by the DHCP RFCs. Atomic writes aren't really an issue - I strongly
> suspect that the server builds a whole lease file record in the buffer and
> passes that in one write operation, and if that's the case, then the only
> non-atomic write issue would be if multiple writes were made (without fsync)
> such that lease file records cross a disk buffer boundaries.
> If a lease file entry were truncated, then I believe the server can deal with
> this on startup by discarding the incomplete record.
>
> So yes, ensuring atomic writes is a by-product of using fsyncs - but not (in
> this case) the primary reason.
I see, so if theoretically the DHCP server could work in such a way as
to "fsync asynchronously" (oxymoron I know), in that the lease could be
written to disk before it is offered to the client, but not necessarily
before the next lease could be served, then this would adhere to the
RFC, represent no real performance penalty, while also not limiting the
rate at which requests can be served.
What changes would be required for this to work? A memory pool of
offered IP addresses which are not to be assigned to new clients?
Rotating a pool of physical disks to store leases in? Multiple
synchronised DHCP servers?
I am just trying to find a solution to this problem that is infinitely
scalable.
LP,
Jure
------------------------------
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 24
*******************************************
