DHCP "static" assignments

Sten Carlsen stenc at s-carlsen.dk
Thu Aug 8 16:21:40 UTC 2013


It seems to me that the man-page is not quite in agreement with this:
~~~~
The *host* declarations will only match a client if one of their
/fixed-address/ statements is viable on the subnet (or shared network)
where the client is attached. _Conversely, for a __*host*__declaration
to match a client being allocated a dynamic address, it must *not* have
any __/fixed-address/__statements. _
~~~~
This text says "not have any fixed-address statements", it does not say
any fixed addresses in this subnet.

I also find the following a bit confusing:
~~~~
The /fixed-address/ declaration is used to assign one or more fixed IP
addresses to a client. It should only appear in a /host/ 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._If none of the addresses in the __/fixed-address/__statement
are valid for the network to which the client is connected, that client
will not match the __/host/__declaration containing that
__/fixed-address/__declaration. _Each /address/ in the /fixed-address/
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"?

On 08/08/13 17:39, Gregory Sloop wrote:
>>> I'm puzzled.
>>> <snip>
> 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!
>
> -Greg
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20130808/5c101aa1/attachment.html>


More information about the dhcp-users mailing list