How can I configure a DHCP server to assign addresses based on the OS that is running Solved maybe!
Sten Carlsen
stenc at s-carlsen.dk
Wed Jun 2 21:49:23 UTC 2010
5.) I have been doing this a number of years. I simply assigned both
interfaces the same IP, with the effect that as they use only one
interface at a time, everything worked even when switching interfaces
during a download.
Whether this is in accordance with the RFC, I am not sure. It worked for
me and was simple.
On 02/06/10 9:23, 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 !
>
> Without looking, I can't say how far back the project goes, but I can
> recall starting with version 3 when it was in a late RC version and
> that was over a decade ago ! Previous versions go a lot further back
> than that. Back when I started with it, I don't think we had **ANY**
> wireless devices in the company.
> As an aside, I was coming to the ISC server as I wasn't happy with the
> way the SCO Openserver one worked (or in my case didn't) - it was a
> lot harder to set up, and lacked virtually every tool you've used in
> your setup. It also had a *serious* bug that AFAIK they never fixed.
>
>> 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.
>
>> 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.
>
>> ---
>>
>> That said, I set up a test network of a variety of clients, and after
>> lots of experimentation I arrived at the following configuration
>> segment, using classes and pools, to assign static IP addresses to
>> clients based on their operating system and interfaces. This has the
>> advantage of showing up in the logs, and if I am correct, gets around
>> the limitations of using host declarations to assign static IP
>> addresses. I won't show my entire dhcpd.conf file as most of it is
>> pretty standard stuff, except for the two declarations I mentioned
>> above. Sorry this is a bit long still, but I limited my test to just
>> 5 systems on a small network.....
>>
>> class "marcslaptop_Vista_Class" {
>> match if ((substring(option vendor-class-identifier, 0, 4) =
>> "MSFT") and
>> ((ucase(binary-to-ascii(16, 8, ":", substring (hardware,
>> 1, 6))) = ucase("0:1a:73:55:7d:f")) or
>> (ucase(binary-to-ascii(16, 8, ":", substring (hardware,
>> 1, 6))) = ucase("0:16:36:c2:65:a4"))));
>> log (info, "marcslaptop_Vista_Class matched");
>> }
>
> I think
> class "marcslaptop_Vista_Class" {
> match if ((substring(option vendor-class-identifier, 0, 4) =
> "MSFT") and
> (hardware=1:0:1a:73:55:7d:f or
> hardware=1:0:16:36:c2:65:a4));
> would work.
>
>> 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.
>
>> 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.
>
--
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/20100602/70c65d21/attachment.html>
More information about the dhcp-users
mailing list