<meta content="text/html; charset=ISO-8859-1"
  <body bgcolor="#FFFFCC" text="#000000">
    It seems to me that the man-page is not quite in agreement with
    <meta http-equiv="content-type" content="text/html;
    The <b>host</b> declarations will only match a client if one of
    their <i>fixed-address</i> statements is viable on the subnet (or
    shared network) where the
    client is attached. <u>Conversely, for a </u><u><b>host</b></u><u>
      declaration to match a client being allocated a dynamic address,
      it must <b>not</b> have any </u><u><i>fixed-address</i></u><u>
      statements. </u><br>
    This text says "not have any fixed-address statements", it does not
    say any fixed addresses in this subnet.<br>
    I also find the following a bit confusing:<br>
    <meta http-equiv="content-type" content="text/html;
    The <i>fixed-address</i> declaration is used to assign one or more
    fixed IP addresses to a client. It should only appear in a <i>host</i>
    declaration. If
    more than one address is supplied, then when the client boots, it
    will be assigned the address that corresponds to the network on
    which it is booting.<u> If none
      of the addresses in the </u><u><i>fixed-address</i></u><u>
      statement are valid for the network to which the client is
      connected, that client will not match the </u><u><i>host</i></u><u>
      declaration containing that </u><u><i>fixed-address</i></u><u>
      declaration. </u>Each <i>address</i> in the <i>fixed-address</i>
    declaration should be either an IP address or a
    domain name that resolves to one or more IP addresses.
    What does it mean "will not match"? Does that mean that the client
    is then an "unknown client"?<br>
    <div class="moz-cite-prefix">On 08/08/13 17:39, Gregory Sloop wrote:<br>
    <blockquote cite="mid:1285884557.20130808083947@sloop.net"
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">I'm puzzled.
      <pre wrap="">
SH> That's OK, confusion is the "normal" state for some of us :)

SH> What you write is correct - you can put an address that's
SH> allocated with a fixed-address statement in a range and prevent
SH> (but see below) it being given to another client by the deny unknown clients option ...
SH> But there's no reason to create the range in the first place -
SH> it's superfluous config. Just using a fixed-address is sufficient
SH> for the client to be given an address - that really is all you need.

SH> But there are two key points you miss :

SH> 1) *ANY* client with a host declaration is known, regardless of
SH> whether it has a fixed address statement with an address *in this
SH> subnet*. Thus you could have a client that should be in another
SH> subnet, but for some reason it gets moved - user "ups and walks"
SH> with it, admin cocks up a VLAN setting, or any number of reasons.
SH> Such a client is still known (it has a host declaration), but it's
SH> fixed-address assignment will be ignored (not valid in this
SH> subnet). Thus it's eligible to be given the dynamic address in a
SH> range you've unwittingly setup specifically for such hosts.

SH> 2) There are other uses for host declarations - and no
SH> requirement that they have fixed-addresses. One such use is to
SH> simply make clients "known". Thus you could (and this works fine
SH> in small networks) have a pool for guests that get one set of
SH> parameters, and another pool for your known devices (which get
SH> different parameters). So the main reason for the [allow|deny]
SH> known-clients is not for blocking addresses out to leave them free
SH> for fixed-addresses, it's for allowing this sort of "my device|visitor" config.

SH> Note that for 1) you *CANNOT* avoid this by trying to "scope"
SH> host declarations within a subnet declaration. You can put host
SH> declarations within a subnet, but host declarations are global no
SH> matter where they are declared. What will happen, and we've had
SH> cases pop up on this list from time to time, is that you get very
SH> strange effects as the hosts inherit some options from the subnet
SH> where it is declared but an address from the subnet where it is
SH> located. The most obvious artifact of this is a client that gets a
SH> router option for a router that isn't in the same subnet as the IP it's been leased !
SH> Since there is rarely, if ever, a need for such inheritance, the
SH> standard advice is to never ever put a host declaration within a
SH> subnet declaration. It is almost certain to create "interesting" problems.

Now *that's* a great explanation, and makes excellent sense. Thanks!
[And Glenn's is too!]

Thanks you both for the excellent run-through...

I can't imagine I'll fall victim to any of the situations you
describe, but I can see how one might.

I do wish the docs were more clear/explicit about host decs. and that they
function as everyone has said.

[Something like: "Clients with matching identification in a host
declaration will get the IP address in the declaration without regard
to any address pools or scopes, as long as the IP address is valid for
the network segment to which the client is connected. IP addresses
included in host declarations should NOT be included in any pools or
scopes." (I'm sure there's language there in my example that could be
improved, but I think the docs ought to be explicit about this, and
from what I've read they are not.)]

Anyway - thanks again for helping me see how mixing the two could
interact, even if not likely in my setup!


dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
    <pre class="moz-signature" cols="72">-- 
Best regards

Sten Carlsen

No improvements come from shouting: