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 (Simon Hobson)
2. Re: Override dynamic lease with static reservation (Simon Hobson)
3. Re: dont-use-fsync real world impact (Niall O'Reilly)
4. Re: Configuring option 82 (Niall O'Reilly)
5. Re: Override dynamic lease with static reservation
(Niall O'Reilly)
----------------------------------------------------------------------
Message: 1
Date: Sun, 29 Sep 2019 16:43:56 +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: <d350af7a-bda4-4332-a33d-df48c54e3...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Jure Sah <e...@juresah.si> wrote:
> 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 suspect it would be a very very major redesign of the code. I would guess a
multi-threaded server where each thread could handle one request - writing a
lease record and responding to the client before being available to handle
another request. As long as the lease record were built in a local buffer and
written in an atomic write, then lease file integrity would be assured.
I suspect it would need a single thread responsible for arbitrating access to
the database - allowing service threads to acquire an address for a client and
mark it as in use as an atomic operation to prevent race conditions between
competing service threads.
Given that the existing single-thread code can handle large numbers of clients
with suitable hardware, and there are methods (see below) for splitting the
load if needed, and there are few users needing this level of performance, I
can't see this being a good use of developer time. Of course, if you really
need something, then the ISC are open to people who will sponsor development
work.
BTW - I don't know how much of this applies to Kea, which is ISCs replacement
for the venerable DHCP server. Not sure of the status at the moment, but at
launch, Kea (while having some advantages) was not feature complete against the
older server.
Jure Sah <e...@juresah.si> wrote:
> Well I quite disagree, even with SSD RAID arrays, the ultimate
> performance is finite, whereas demands on a DHCP service for instance by
> mobile clients is quite significant and it's easy to have too many
> customers for a single server.
You can have multiple servers on a network.
It's a bit more involved if you have a huge flat network, but that would be
poor network design anyway. Particularly if you have multiple networks
(different subnets, or more correctly, multiple broadcast domains) then it's
fairly easy to have different servers (or pairs) serving groups of networks.
You can also have multiple failover pairs, and a server can be in different
failover relationships with different pools. You can have (say) four servers on
one network, either as simply A-B and C-D with half the available pool
configured on each pair, or it can be done A-B, B-C, C-D, and D-A with a
quarter of the pool configured on each failover pairing. Particularly with the
latter arrangement, you can reduce overlap on DHCP-Discover messages by getting
one half of each pair to ignore clients until they have been trying for a
certain time, or perhaps using Agent-CircuitID (at the expense of more
processing).
In the past, one rather ingenious idea was to have a local server at each
access point (the specific case in mind was a distributed wireless access
system where access points did not necessarily have battery backup) - with no
permanent storage. Each of these servers has a failover pairing with a central
server. Normal operation is handled by the remote server using RAM-disk for
very fast storage with failover (which is async) providing a backup to the
central server. If the remote server fails or has maintenance etc, a relay
agent can be turned on to allow the central server to handle clients, and the
remote server can reload it's database from the central server using the
failover protocol when it restarts. This does, however, trade off a certain
amount of risk in that there is a window between local operations and the
result being reflected via failover in the central database.
So a few options there.
------------------------------
Message: 2
Date: Sun, 29 Sep 2019 17:22:44 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Christian Kratzer <c...@cksoft.de>, Users of ISC DHCP
<dhcp-users@lists.isc.org>
Subject: Re: Override dynamic lease with static reservation
Message-ID: <b1d7e253-ecf2-486f-868b-c58e4947a...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
Christian Kratzer <ck-li...@cksoft.de> wrote:
> Summary:
>
> This is default isc dhcp behaviour.
>
> From all that I remember from looking at the code host always takes precence
> from dynamic leases.
Well, I've just checked and concur - adding a host entry with fixed address
does cause a request for the dynamic lease to be Nacked - lease unavailable. A
discover is replied to with the fixed address. That's with version 4.2.2.
There must have been a change somewhere, because I do recall that in the past
(and it's going back some years now) I distinctly remember having to edit the
leases file to remove dynamic leases in order to force clients to get the fixed
address. Just adding the host entry was not sufficient at some time in the past.
------------------------------
Message: 3
Date: Mon, 30 Sep 2019 08:55:32 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: dont-use-fsync real world impact
Message-ID: <f2b7967d-893a-460b-8483-f329a7ba8...@ucd.ie>
Content-Type: text/plain; markup=markdown
On 28 Sep 2019, at 12:33, Jure Sah wrote:
> 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?
Have you read the documentation for the delayed-ack and max-ack-delay
statements?
> [...]
>
> I am just trying to find a solution to this problem that is infinitely
> scalable.
To echo Steinar Haug, neither the network nor the client population is
infinitely scalable.
IMHO, it makes sense to have infrastructure scale in proportion to
demand, and to use monitoring to identify both when there is insufficient
headroom and where the real choke-points are.
The most significant bottleneck to DHCP services which I ever had to deal
with was due to excessive fsync in the syslog process, not even in dhcpd.
Niall O'Reilly
------------------------------
Message: 4
Date: Mon, 30 Sep 2019 10:58:47 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: Configuring option 82
Message-ID: <e1dd6580-f4f2-4911-af25-026f85318...@ucd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
On 27 Sep 2019, at 12:32, Surya Teja wrote:
> In one of the google forum I have read the statement saying like?
>
> The internal implementation in ISC DHCPD of classes is such that it
> scales in a non-linar way - O(N^2) or something. So suddenly you'll
> end up with dhcpd eating 100% CPU.
>
> So I just want to avoid the classes?
I think you may find that the documentation for dhcpd.conf,
if you read it carefully, will give you more useful insight
than "one of the google forum".
In particular, this:
SUBCLASSES
In addition to classes, it is possible to declare subclasses. A
subclass is a class with the same name as a regular class, but
with a
specific submatch expression which is hashed for quick matching.
This
is essentially a speed hack - the main difference between five
classes
with match expressions and one class with five subclasses is
that it
will be quicker to find the subclasses.
I hope this helps.
Niall O'Reilly
------------------------------
Message: 5
Date: Mon, 30 Sep 2019 11:08:08 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: Override dynamic lease with static reservation
Message-ID: <b472b7f4-981d-49ad-ae86-2123d1872...@ucd.ie>
Content-Type: text/plain; markup=markdown
On 29 Sep 2019, at 17:22, Simon Hobson wrote:
> Just adding the host entry was not sufficient at some time in the past.
>From my experience, I can confirm this.
Configuring 'deny known-clients;' in the relevant pool specification(s)
was enough to prevent continued use of the previously-used dynamic
lease.
Niall O'Reilly
------------------------------
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 26
*******************************************
