Restricting leases

[Jason Gerfen]

Good morning Patrick,

While the typical RTFM is always encouraged I believe the option(s) that
will benefit you the most regarding a wildcard whitelist of nodes per
network segment would be the section within the dhcpd.conf titled 'client
classing' & 'subclasses'.

The examples provided should give you some insight into allowing devices
based on the hardware identifier or other unique device identifiers. More
information on these can be obtained in RFC-2132 (
https://www.ietf.org/rfc/rfc2131.txt) table 3 (fields and options in a DHCP
message).

Hope this helps

On Thu, Jan 29, 2015 at 9:12 AM, Patrick Trapp <ptrapp at nex-tech.com> wrote:

>  First, an apology - I'm not even sure how to ask this question, so my
> pre-post research really got me nowhere. So I'm really looking for a
> direction as much as an answer - I hate wasting people's time asking a
> question when I don't really know enough to ask the question well.
>
> Second, the question(s) - Can we/how can we/should we limit the devices
> that the DHCP server provides addresses to? For example, legitimate devices
> on this network are 80% produced by two specific manufacturers. There
> should be virtually no workstations on this network - legitimate
> workstations accessing this network will do so via another network and get
> their addresses from a different DHCP system. The only reason a workstation
> should be on this network is if a technician is troubleshooting.
>
> So I am looking at the viability of allowing devices from the known
> manufacturers and whitelisting the specific devices carried by our
> technicians and not providing addresses for unexpected devices.
>
> I fully expect and deserve an RTFM - I'm hoping someone can give me some
> ideas where I should be looking and what key words will get me where I need
> to go.
>
> Thanks for reading,
> Patrick
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at 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/20150129/b3d0a792/attachment.html>