DHCP "static" assignments

[Glenn Satchell]

Hi Greg

My responses are inline below. It's ok to be puzzled, dhcpd has a rich
configuration language, and to borrow from Perl TMTOWTDI. That doesn't
mean that just because it works means it's the "right" way or Best
Practise.

On Thu, August 8, 2013 11:47 pm, Gregory Sloop 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
> documentation.
>
>
> From the dhcp.conf man page...
> ---
> ALLOW DENY AND IGNORE IN SCOPE
>        The following usages of allow and deny will work in any scope,
> although it is not recommended that they be used  in  pool
>        declarations.
>
> 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
>        DECLARATIONS.
> --- AND ---
> ALLOW AND DENY WITHIN POOL DECLARATIONS.
> ...
>  known-clients;
>
>        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.
>
>         unknown-clients;
>
>        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 address...

True, except for the last bit about the host declaration. The host
statement does not block other clients from getting that address if they
match the allow/deny requirements for the pool. In your example any other
known clients that do not have a fixed-address statement are potentially
able to get that address. the way to ensure no other clients can get the
address is to not include it in the range.

> 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?

You can have a host declaration without a fixed-address statement. That
makes it a known client that still wants to get an address from a dynamic
range.

Examples have already been given of how you can get devices with duplicate
ip addresses so I won't repeat them here. There is asection titled IP
ADDRESS CONFLICT PREVENTION in the dhcpd,conf man page.

> 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.]

See also the dhcpd man page:

Subnets
     dhcpd needs to know the subnet numbers and netmasks  of  all
     subnets  for  which it will be providing service.   In addi-
     tion, in order to dynamically allocate addresses, it must be
     assigned  one  or  more  ranges  of addresses on each subnet
     which it can in turn assign to client hosts  as  they  boot.
     Thus,  a  very  simple  configuration providing DHCP support
     might look like this:

          subnet 239.252.197.0 netmask 255.255.255.0 {
            range 239.252.197.10 239.252.197.250;
          }

     Multiple address ranges may be specified like this:

          subnet 239.252.197.0 netmask 255.255.255.0 {
            range 239.252.197.10 239.252.197.107;
            range 239.252.197.113 239.252.197.250;
          }

     If a subnet will only be provided with BOOTP service and  no
     dynamic address assignment, the range clause can be left out
     entirely, but the subnet statement must appear.

> 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.

Now looking at dhcpd.conf, in the section DYNAMIC ADDRESS ALLOCATION.

     There may be a host declaration matching the client's  iden-
     tification.   If  that  host  declaration  contains a fixed-
     address declaration that lists an IP address that  is  valid
     for  the  network  segment to which the client is connected.
     In this case, the DHCP server will never do dynamic  address
     allocation.   In  this  case, the client is required to take
     the address specified in  the  host  declaration.

Not doing dynamic allocation means that it does not make use of any range
statements.

And further down in the same man page.

     The host statement

      host hostname {
        [ parameters ]
        [ declarations ]
      }

     The host declaration provides a scope in  which  to  provide
     configuration  information about a specific client, and also
     provides a way to assign a client a fixed address.

If you look at the rest of that section there is no mention of the
requirement to have a corresponding entry in a range statement.

> 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 to 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.

That's fair enough. The man pages are quite long, and have evolved over
many years, so sometimes they do not always have perfect continuity or
entirely logical layout.

This reply is intended to be in the spirit of your question, and I hope it
comes across that way.

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

The version shouldn't make any difference, this behaviour has been around
since the very first versions.

A few years ago there was a book The DHCP Hanbdbook (2nd Ed) which you can
still get on Amazon
http://www.amazon.com/The-DHCP-Handbook-2nd-Edition/dp/0672323273 This is
considered the definitive reference guide for configuring ISC DHCPD. Ralph
Droms is the chair of the IETF working group for DHCP and editor of the
dhcp RFCs. Ted Lemon is the original author of ISC dhcpd. So I think these
guys know what they are talking about :)

regards,
-glenn

> TIA
> -Greg
>