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 server configuration does not work for all clients
(Niall O'Reilly)
2. Re: multi interfaces(vlans) configuration (Simon Hobson)
3. Re: DHCP server configuration does not work for all clients
(Jim Yang)
----------------------------------------------------------------------
Message: 1
Date: Thu, 08 Oct 2020 20:46:22 +0100
From: "Niall O'Reilly" <niall.orei...@ucd.ie>
To: "Users of ISC DHCP" <dhcp-users@lists.isc.org>
Subject: Re: DHCP server configuration does not work for all clients
Message-ID: <a2f32e40-e39a-4dcd-a713-25756e84f...@ucd.ie>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 8 Oct 2020, at 20:25, Jim Yang wrote:
> Is this a DHCP sever software bug or something else?
Whenever I?ve been surprised by behaviour like this,
it?s been due to a subtle bug in my configuration,
and never to a server software bug.
You show us
subclass "mytest" 1:74:A7:11:22:33:44;
but I can?t see your definition for
class ?mytest? { ? }
so can?t tell what the value in your `subclass`
statement is being matched against.
It?s been a while since I?ve needed to configure and run an ISC DHCP
server,
so I had to check the relevant section of the documentation:
https://kb.isc.org/docs/en/isc-dhcp-44-manual-pages-dhcpdconf#SUBCLASSES
/Niall
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20201008/c617e19d/attachment-0001.htm>
------------------------------
Message: 2
Date: Thu, 8 Oct 2020 20:51:58 +0100
From: Simon Hobson <dh...@thehobsons.co.uk>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: multi interfaces(vlans) configuration
Message-ID: <2ad27c59-439a-4994-a4a3-a3d3161c0...@thehobsons.co.uk>
Content-Type: text/plain; charset=us-ascii
ahiya <ah...@younity.io> wrote:
> I'm new to isc/kea.I have multi-sites with around 2000-5000 devices per
> site.the real issue is that they are spread across 500 different VLANs.I
> wanted to know is isc/kea is the right solution for that task.and what is
> the right way to implement it?
There isn't really a right or wrong way to do it - just different trade-offs.
> Raspberry PI4 with 8G mem will be enough?
I've not kept up, but does the Pi4 now have a proper ethernet and means of
attaching a disk ? I know earlier models had a USB-ethernet bridge which is far
from ideal.
> should I use .conf files or should I go for the backend server?
As another has said, you would be well advised to automate with that size of
setup. Manually configuring that size of config (without errors !) will be a
nightmare - so put the config in some sort of config management and script
generation of the config files for the servers.
Ahiya Zadok <ah...@younity.io> wrote:
> Regarding the number of sites- I plan to have a server per site.
> Each site will have around 500 subnets with around 10-15 devices per
> subnet.
> Does the number of IPs per subnet affect memory even when they are not
> assigned?
Yes, memory requirements scale (I believe) roughly linearly with number of IP
addresses available in your config - even those that have never been assigned.
So the size of each pool in each of your 500 subnets will make a massive
difference to memory requirements.
Note that once an IP has every been leased to a client, it will remain in the
leases file "forever". The server will never delete it unless you remove the IP
address from the config (remove/change a range). Eventually, when all addresses
have been used once, the server will start to re-used old leases in a least
recently used manner.
Ahiya Zadok <ah...@younity.io> wrote:
> Do you think that the numbers of subnets and the number of interfaces
> (vlans) that DHCP is listening to have much effect on resource
> utilization?
No, number of subnets makes a fairly small impact on memory requirements - it's
number of IP address that makes the big difference. So 500 subnets with (say)
50 IPs each (250,000 in all) will take a lot less memory than the same 500
subnets with (say) 250 IPs each (1,250,000 in all).
Ahiya Zadok <ah...@younity.io> wrote:
> The network gear in my sites is the bottleneck
> It supports up to 256 DHCP servers/relay agents.
Are you sure that's a limitation ? In principle you only need one or two (if
you use failover) per network device - remember you only have one or two
servers to forward requests to. I would be surprised if a device didn't support
at least one ip-helper per interface, or a small number globally.
> Do you think that raspberry pi could handle 500 VLAN interfaces?
I've never gone about 30-something interfaces in Linux. In principle I would
have thought it could handle it - we hear of people running hundreds of virtual
machines on a host, and each of those gets one (or more) virtual network
interfaces. But it's probably easier to just add one (or two) ip-helper
addresses to the routers.
A few more thoughts in no particular order ...
What are you planning to do regarding fault tolerance ? With that many devices,
I imagine loss of the DHCP service would quickly start to cause problems - and
the corresponding enquiries from customers. You could run two servers per site
- either in failover, or with non-overlapping ranges but the same subnets. The
latter would mean clients changing address is the server they got their address
from fails, and the DNS would not get updated - but they would continue to work.
One idea from a long time ago was to run small servers out in the network, and
a central massive server. Each small server would have a failover relationship
with the central server - so the central server would hold a copy of all the
leases (where it's relatively easy to provide fault tolerance (RAID, UPS, etc)
and backup.
At the edge, the servers would run diskless, storing the lease database on
ramdisk - and after a restart would load the leases database from the central
server via failover. Whether this would work with that many clients per site
would be interesting to know.
You don't have to run diskless at the edge - that was mainly a suggestion to
avoid all the issues that come with having storage dotted around remote sites
where it's hard to manage and involves an engineer visit if anything goes wrong.
During normal operations, clients will use the local server because it will
normally respond first due to being closer (in terms of network links and
latency). If the local server is down, they will be able to use the central
server.
When sizing the system, you need to consider other than just the steady state.
Even a modest server can manage many clients if the leases are long - but what
happens if there's a mass event such as a power cut that causes many clients to
re-connect in a short space of time ?
In such an event, your server will experience a significantly higher load -
which will be higher if all the devices auto-startup when power is restored,
but lower if it's (e.g.) desktop systems that need the user to power them on.
It's not as simple as "a queue will form".
If the server can't cope, clients will send a request, and eventually time out
waiting for a reply - they'll then send another request, and another, and ...
with man of the requests getting dropped. That in itself might not be too bad -
clients would be happy when they hit the jackpot and their packet in one of the
ones that didn't get dropped. But it's not that simple - many devices (and
every device without both a real time clock and persistent storage) will first
send a discover, then after it gets an offer will send a request (the DORA
cycle, Discover-Offer-request-Ack). If the client doesn't get an Ack to it's
request, it will eventually go back to sending Discovers.
In extreme, it could be a very long time before clients get addresses and the
load dies down. And disk usage (for the leases file) will also temporarily
increase - each transaction results in a new record being appended to the end
of the file.
Simon
------------------------------
Message: 3
Date: Thu, 8 Oct 2020 20:55:11 +0000
From: Jim Yang <z...@cornell.edu>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP server configuration does not work for all clients
Message-ID: <6b4df24a-5778-4b5e-96df-b0a537c4a...@cornell.edu>
Content-Type: text/plain; charset="utf-8"
Hi Niall,
Thank you for your reply.
class ?mytest? {
match option dhcp-client-identifier;
}
It seems that I should change the class definition to match either option
dhcp-client-identifier or hardware.
class ?mytest? {
match pick-first-value (option dhcp-client-identifier, hardware);
}
Thanks,
Jim
From: dhcp-users <dhcp-users-boun...@lists.isc.org> on behalf of Niall O'Reilly
<niall.orei...@ucd.ie>
Reply-To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Date: Thursday, October 8, 2020 at 3:46 PM
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: DHCP server configuration does not work for all clients
On 8 Oct 2020, at 20:25, Jim Yang wrote:
Is this a DHCP sever software bug or something else?
Whenever I?ve been surprised by behaviour like this,
it?s been due to a subtle bug in my configuration,
and never to a server software bug.
You show us
subclass "mytest" 1:74:A7:11:22:33:44;
but I can?t see your definition for
class ?mytest? { ? }
so can?t tell what the value in your subclass
statement is being matched against.
It?s been a while since I?ve needed to configure and run an ISC DHCP server,
so I had to check the relevant section of the documentation:
https://kb.isc.org/docs/en/isc-dhcp-44-manual-pages-dhcpdconf#SUBCLASSES
/Niall
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20201008/15a17b72/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
dhcp-users mailing list
dhcp-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 144, Issue 5
******************************************
