How can I configure a DHCP server to assign addresses based on the OS that is running Solved maybe!
Marc Chamberlin
marc at marcchamberlin.com
Thu Jun 3 00:55:42 UTC 2010
On 6/2/2010 12:23 AM, Simon Hobson wrote:
> Marc Chamberlin wrote:
>
>> Thanks everyone for all your help, it gave me a lot to explore and
>> was a big help. I have spent quite a few days on this, and though I
>> hate throwing stones at a project, with as much invested in it as
>> this one apparently has, and been around as long as it has, I am
>> quite surprised at how difficult it is/was to work with and configure
>> this server. I think a redesign, with particular attention paid to
>> the model and configuration language should be seriously considered,
>> but that is just IMHO.... Also, a number of (ok maybe I should say
>> possible) bugs have surfaced during the course of my investigations,
>> which made it far more difficult to find a solution, than it should
>> have been. I will go through these and then present what I think is a
>> solution and ask for opinions, since much of the underlying model is
>> undocumented, (as far as I could find) in particular the precedence
>> that is used by the server as it builds it's database and decision
>> tree for IP address assignments.
>
> To a certain extent you are right, but you have to remember that there
> is a certain amount of "we wouldn't start from here" ! The latest
> versions have a new feature that may be useful (reserved leases), and
> there is another feature on the wish list (redefine the primary key)
> that is as yet unimplemented but would solve (or at least help) quite
> a few usage cases like yours.
>
> Bear in mind that AFAIK, the ISC server is waaaay more adaptable than
> most. And you are in fact asking for functionality that it wasn't
> designed to do (and is arguably not in accordance with the standards).
> You may have found it difficult, but you achieved it - no other server
> that I have any experience with would do anything even remotely close.
> Back when this server was started, people were still using BOOTP and
> reverse ARP to configure clients - DHCP was a real leap forward !
>
Simon, thanks for taking the time to respond, I think fundamentally we
agree. I am not debating whether this dhcp server and the standard
behind it was the best available at the time of conception. Nor am I
debating the point that it has adapted somewhat to changing demands,
such as meeting the requirements for what I am trying to place on it.
And yes it may still be flexible enough to allow me to accomplish my
goals, but it was and still is difficult for me to KNOW that what I want
will be accomplished, because I am guessing about the intent of the
definitions I used and what they imply.
My main point in saying that perhaps a new design should be considered,
is derived from two things to consider.
1. The fact that the language constructs used to configure the server
did not really do a good job of revealing the underlying architecture
and data/execution models of the server. Nor did they allow me to easily
predict just how the server is going to behave, when definitions in the
config file are created and set. You yourself recognized this when you
say that things like Accept and Deny statements are not processed in a
linear fashion and you don't recommend using them together. And we both
agree that the host declarations, in their current form, are not
sufficient for static IP address assignments. I am saying that it is
hard to discover just what and how the dhcp server is going to behave,
from looking at the language constructs used to define it's behavior.
2. Technology is moving onwards and new demands, such as handling
computers with multiple dynamic network interface requirements, is
emerging. As you point out, this was not an issue when the DCHP standard
and this server was designed. You also allude to the fact that I am not
the first person to report having difficulties meeting dhcp requirements
in current network environments.
>
>> 2. The hardware "object" while it may be convenient in some cases, I
>> submit it is confusing and difficult to work with. The underlying
>> data structure for this object is actually two fields, a hardware
>> type identifier and a numeric encoded mac address. I don't understand
>> the need to bond the hardware type with the mac address so tightly,
>> and not provide any easier objects for users to work with and
>> manipulate instead. It took me quite awhile to figure out how to use
>> this object effectively, given my goal of using the mac address of
>> the client's interface in conditional expressions! See below..
>
> I'm not with you here. What is hard about "hardware ethernet
> aa:bb:c:d:ee:ff ;" ? You don't need all those binary-to-ascii and
> substring constructs you are using (I think). While you may think it's
> complicated to have a hardware type element, it is required as
> different hardware types have different identification constructs -
> and there was no way of knowing what new types may come along in the
> future.
It is not hard to use a complex object once you discover and understand
it. What makes it hard is that this particular hardware object is a
different model from what (I believe) most people will think of as a
hardware address. Most programs that use hardware addresses are
referring to what is called a MAC address which has (I believe, could be
wrong...) a common form of 6 hex digits separated by colons. From the
dhcp servers own display of what are hardware addresses, in log files,
in dhcp.leases and in the configure language, it is in fact
inconsistent, sometimes using a 7th hex digit and sometimes using the
interface type name. This first form of a hardware address is easily
confused with MAC addresses, and it fooled me! It would have been more
convenient to have a simple MAC address object to work with, that
matches the common form of MAC addresses. The "hardware" object requires
one to discover the extension that is employed, to define the type of
interface as well. I used examples from the documentation and I easily
overlooked this detail about the interface type, as it went against my
assumptions based on past experiences. So I reported it because it made
it hard to discover what had gone wrong when I accidentally misused
it. I won't argue this issue very strongly, but simply say that good
language designs take into account the sort of assumptions that users
are likely to make.
>
>> 5. In order to handle clients with more than one interface, and allow
>> clients to dynamically switch between different interfaces, I
>> included the following two statements in my dhcpd.conf file -
>>
>> deny duplicates;
>> ping-check on;
>>
>> My goal was to force a static IP address assignment to a particular
>> client, by using the class and pool declarations shown below, in
>> conjunction with these declarations. I noted instead, that if a
>> client booted up and initialized one of two interfaces (wired or
>> wireless) then switched interfaces (disabling the first initialized
>> interface in the process) that the dhcp server was unable to transfer
>> the IP address assigned to the first interface to the second one
>> based on a simple DHCPREQUEST. Instead the transfer only occurred if
>> the client reinitialize his interface and forcing a DHCPDISCOVER
>> instead.
>>
>> Perhaps this is correct dhcp behavior, but I would think that doing a
>> ping check and discovering that the client is no longer responding to
>> it, would have been sufficient to prevent the user unfriendly
>> requirement of having to reinitialize an interface just because it
>> was hot-plugged and/or the user turned the other off. So I am confused!
>
> Again, you are hitting a situation that was never envisaged when the
> DHCP standards were written. The "problem" is that the way you want it
> to work is explicitly not in accordance with the standards. It is a
> known problem, that's why the deny-duplicates was introduced to try
> and mitigate it to a certain extent. Ping-check has nothing whatsoever
> to do with what you are trying to achieve, and is in fact merely a
> "safety net" to try and avoid problems from some common network
> misconfigurations.
Yep, here we are in agreement, neither the documentation nor the
language constructs allowed me to discover how to handle this situation.
I had to guess, for example, about what Ping-check might do for me based
on what little documentation I could find about it.
>
>> subnet 192.168.2.0 netmask 255.255.255.0 {
>> default-lease-time 14400;
>> max-lease-time 172800;
>> pool {allow members of "marcslaptop_Linux_Class"; range
>> 192.168.2.10;}
>> pool {allow members of "marcslaptop_Vista_Class"; range
>> 192.168.2.15;}
>> pool {allow members of "nova_Linux_Class"; range 192.168.2.20;}
>> pool {allow members of "nova_XP_Class"; range 192.168.2.25;}
>> pool {allow members of "darkstar_2000_Class"; range 192.168.2.35;}
>> pool {allow members of "stephslaptop_Vista_Class"; range
>> 192.168.2.45;}
>> pool {allow members of "teraserver_Class"; range 192.168.2.50;}
>> pool {
>> deny members of "marcslaptop_Linux_Class";
>> deny members of "marcslaptop_Vista_Class";
>> deny members of "nova_Linux_Class";
>> deny members of "nova_XP_Class";
>> deny members of "darkstar_2000_Class";
>> deny members of "stephslaptop_Vista_Class";
>> deny members of "teraserver_Class";
>> deny known-clients;
>> allow all clients;
>> range 192.168.2.101 192.168.2.199;}
>> }
>>
>> There are a few things of note in the pool declaration for the final
>> pool segment that assigns IP addresses to unknown clients.
>>
>> 1. I added the deny members of "class" statements to prevent an IP
>> address assignment to a client which activates a second interface.
>> This requirement surprised me, but it seems to work.
>
> Why surprised ? Unless you specify that a client should not be allowed
> to use a pool, then it can use a pool. It is deliberate that allowing
> it in one pool doesn't exclude it from others as that would create
> just as many complaints.
I was surprised for several reasons... I had used the "deny duplicates"
and "ping-check on" in declarations, which I though might cover this
situation. And I don't have the inside knowledge of the model used by
the dhcp server with regards to how pools of addresses are handled and
allocated. You are correct in saying that whatever choice was made, to
model the usage of a pool, users will complain. But the language
construct does not reveal how the pools will be used and I had to guess.
My first guess was wrong.. so for these reasons I was surprised..
>
>> 3. The allow all clients statement is a guess on my part, as nothing
>> is said about precedence of configuration statements in the
>> documentation. But my guess is that this will allow assignment of an
>> IP address to all unknown clients without my having to specify all
>> clients on my network with host statements. If this won't work, and I
>> have to use the allow unknown clients statement instead, then I would
>> be right back to where I started from, having to specify hosts
>> declarations, which I am trying to get around due to their inadequate
>> capabilities. I have not yet fully tested this to my satisfaction,
>> but initial trials seem to indicate it works....
>
> That is an area that could do with improvement, and it comes up fairly
> frequently. Mixing allow and deny is generally advised against as it
> does NOT give the results most people expect - specifically the allow
> and deny statements are NOT processed linearly.
>
Hence my suggestion that a redesign effort might be in order.... ;-) I
don't think my requirements are all that far out of line and the need is
real. It appears that this dhcp server has had quite a bit of "upgrades"
and "enhancements" made already, over the years, and the ever expanding
requirements are stretching it's capabilities, as well as perhaps the
underlying standards. I had to do some guessing, which is never a good
plan, and try to stretch the server's capabilities to meet my own
requirements...
Finally, one question - Is the fact that log statements are not produced
when the dhcp server fails to assign an address to a client, in fact a
bug and should it be reported? That was a pretty serious handicap for me....
Anywise, as you hinted in an earlier response... who is going to fund a
redesign effort, or even another upgrade? Sigh...
Marc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6464 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100602/26532599/attachment.bin>
More information about the dhcp-users
mailing list