DHCP "static" assignments

Steve van der Burg steve.vanderburg at lhsc.on.ca
Thu Aug 8 14:18:51 UTC 2013

It's been awhile since I looked that carefully at the documentation, but
my 19,260 static assignments outside of pools would argue that the
"assign static (unchanging) addresses outside of ranges" strategy works
A really quick skim of the docs does seem to indicate that ranges are
for dynamic allocation (and pools are just a way to encapsulate them for
Anyway, I've got a CGI app that our staff use to map MACs to IP
addresses and then some perl code that uses Expect and omshell to add,
remove and change host containers/stanzas inside the lease files on
running DHCP servers.  It reads the lease file to determine current host
assignments, then reads the state of the CGI app's database, figures out
the delta and then uses omshell to apply it.

>>> Gregory Sloop <gregs at sloop.net> wrote:

I'm puzzled.

I decided to read the docs [again] *very* carefully, since I'd gone
over them before fairly carefully and was a bit surprised at the
responses I got yesterday saying that I shouldn't include the IP
address in the host dec. in the pool at all. [And that bad things
would happen if I *did* have it in a pool, even with the "deny
unknown-clients" clause/directive.]

It *appears* that the recommendation given yesterday will work, given
everyone's experience. [I have not tried it yet, and I am and have
been running it my way for years.]

But it appears the way I am doing it most closely matches the

>From the dhcp.conf man page...
	   The following usages of allow and deny will work in any
scope, although it is not recommended that they be used  in  pool

The unknown-clients keyword

	    allow unknown-clients;
	    deny unknown-clients;
	    ignore unknown-clients;

	   The  unknown-clients  flag  is  used  to  tell  dhcpd 
whether or not to dynamically assign addresses to unknown clients.
	   Dynamic address assignment to unknown clients is allowed by
default.  An unknown client is simply a client  that  has  no
	   host declaration.

	   The  use  of  this  option is now deprecated.  If you are
trying to restrict access on your network to known clients, you
	   should use deny unknown-clients; inside of your address pool,
as described under the heading ALLOW AND DENY  WITHIN  POOL
--- AND ---

	   If specified, this statement either allows or prevents
allocation from this pool to any client that has a  host  declaraâ
	   tion (i.e., is known).  A client is known if it has a host
declaration in any scope, not just the current scope.


	   If  specified, this statement either allows or prevents
allocation from this pool to any client that has no host declaration
	   (i.e., is not known).

So, not to complain about the help you all have given, but it appears
to me that this says that having a host declaration makes it a "known
client" and that if you use the "deny unknown-client" directive in the
pool, NO unknown clients will get that address, and the host
declaration should ensure that no OTHER client should get that

So, in what cases are you all claiming that having it declared in the
pool, but with a host definition *and* a "deny unknown-clients" would
result in the IP defined in the host declaration [and in the pool,
with a "deny unknown-clients" clause] getting assigned to anyone else?

Next, while it may work, not having the address in any pool, doesn't
match the docs, at least in intent. [Again, my reading of the docs.]

It looks to me as if the docs INTEND for you to have the address in a
pool, and restrict the assignment via the "deny unknown-clients"
clause inside the pool.  

I really don't want to start a war here - I'm just trying to make
sense of what appear to be deviations from the docs. Perhaps I
misunderstand the docs, or perhaps the explanations given do. I just
want t
o make sure I really grok what's intended, as well as how it
might practically work - even if the docs don't describe it that way.

[I'm running 4.1-R4, BTW - the standard Ubuntu package.]


dhcp-users mailing list
dhcp-users at lists.isc.org

This information is directed in confidence solely to the person named
above and may contain confidential and/or privileged material. This
information may not otherwise be distributed, copied or disclosed. If
you have received this e-mail in error, please notify the sender
immediately via a return e-mail and destroy original message. Thank you
for your cooperation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130808/bea81123/attachment.html>

More information about the dhcp-users mailing list