DHCP "static" assignments

[Simon Hobson]

Gregory Sloop wrote:
>I'm puzzled.
> <snip>

That's OK, confusion is the "normal" state for some of us :)

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


But there are two key points you miss :

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

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


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