I've searched on issues of multiple DHCP servers in one LAN. Just about everything is Windows or Novell based stuff. Also, the typically asked scenario is 2 or more DHCP servers for failover purpose (one goes down, the other takes over).

What I want to do with DHCP is different. My purpose would best be described as "administrative separation". Basically, if a given MAC address is configured on a specific DHCP server, that server should be the one to answer and not the other. The problem with that is that we also need a default to handle unknown MACs. So the DHCP server without the MAC configured would be answering, anyway, even if it is the only one configured to do global leasing. Timing would then be the determining factor.

The purpose is to set up a bunch of PXE network booting using program generated DHCP configuration. This server won't always be up, so it can't be used for general purpose. The DHCP server for general purpose is part of a wireless system, and it is configured by GUI and is impractical for the programmed PXE booting.

Any ideas on how to make these work together with everything being on the same LAN segment?

Googling for "dhcpd ignore" tells me there is a "booting ignore" option you want to check out.

Thanks. It seems Ubuntu's packages (maybe Debian's) have left out many of the man pages (though not all) for DHCP. I guess I need to get source code just to see man pages.

*** Ignore this post. I had wrong packages installed.

I think I got the right man page, now. There is "allow booting", "deny booting", and "ignore booting". But there is no definition of what this means. Does it distinguish between machines asking for configuration info in BIOS before a kernel is loaded (e.g. ready to do a network boot), and machines that are currently booting a system (e.g. getting IP address for the very first time)?

I would like for our general purpose DHCP server (not the one I am setting up) to NOT handle the case of machines doing a network boot from BIOS, but to still handle the case of machines where the OS asks for an address (and DNS servers, etc). I would like for the new DHCP server (this is the one I am setting up) to handle all, and only, cases of machines doing a network boot from BIOS (to tell them where to get the boot image ... which will be the same server).

If it happens that machines will get one IP address and a boot image from one DHCP server (the new one), and later that OS gets a different IP address from the general purpose DHCP server, that would be OK. But it's also OK if the machines that did a PXE boot also got their OS running IP from the same DHCP server as they did during BIOS boot doing PXE.

One difficulty is that the existing general purpose DNS is run by a wireless multi-access-point controller and serves both the wireless and wired users that don't statically configure an IP address. It doesn't seem to have as much configuration choice as ISC DHCP (which seems to have an over abundance).

Can I suggest that rather than describing this all in such length you just do exactly what i did and get your answers much more quickly?

I don't understand. I have googled for what you googled for, but nothing that specifically matches the concepts comes up. But I can't tell about "ignore" because it isn't telling me what I need to ignore. As far as I can tell, I need to NOT ignore something. What is my DHCP server supposed to ignore? This makes no sense.

Well you want to ignore a subset of known clients, right? Each dhcp server clearly MUST know about ALL clients, in order to know what is unknown (hmm, cue donald rumsfeld...). So if you want to not serve dhcp to a specific client from a specific server then that server needs to be told the client exists, and that it should ignore its requests.

No.
I want every client that is trying to do a BIOS based network boot (where it would get an IP address and file name and do a TFTP transfer of a kernel image and run it) to get information from the new Linux based DHCP server to support this network booting. All other requests should be answered by the regular DHCP server (based in a router).

When I do try to do a BIOS based boot, it retries several times and gets no answer, when only that regular DHCP server is running. I do not know if this means it is not even getting an IP address, or not. Maybe it gets no IP address and stops there (it retries 5 times from the netbook I tested with). Or maybe it gets an IP address but doesn't get a file name (the router has no means to configure this, anyway), and that's what causes it to fail.

Some concepts are needed here that every DHCP document I have seen is not answering. One question is "can DHCP provide info only from a single server or will multiple non-conflicting answers from multiple servers be merged?".

It may be that in order to do any PXE at all, we have to migrate our DHCP away from the router and provide for a server specifically to do that for every aspect. If that is the case I need to find some definitive document that says this so I can justify carrying out the migration.

The resources on the net are great if what one is doing is the same as what everyone else does. But once there is some significant difference, then the net is basically just noise (often loud). Maybe there is some keyword to look for that matches what I'm doing which I am not aware of? But it's definitely not "ignore" based on the concepts I already understand.

Insofar as the things that are not being answered, I don't find that surprising as I'd not expect anyone to ever think DHCP would merge multiple lease offers from different servers, that's just nuts.

Whilst there is stuff to research for the Linux server side (I'm not sure offhand if there is a clear reliable difference between a DHCP request for a PXE and a normal request), it's all irrelevant if the router DHCP still responds anyway. Unless that route DHCP instance will *IGNORE* those requests, you're stuffed. As you speculate, you'd really benefit by taking DHCP into a single location and go from there. Just because you can get "free" dhcp on a Cisco router (or a crap router) doesn't mean you should use it or that it is preferable in any way to using a proper server. DHCP has such a low load in general who cares if you uise it for more than you expected?

Is it really nuts? I don't know. Or at least I didn't know that before asking here, based on the documentation. Since it is initially a broadcast request, it is very plausible to do that. Since you say so (that it is nuts), I guess that is some information I am looking for.

At this point, then, I guess I need to understand how DHCP behaves, or is supposed to behave, when more than one DHCP server is present and answers a request. Is it simply based on the first answer received? Or is it based on the best answer (e.g. supplies the most information requested) received?

I agree that DHCP is a low load. It's lower than DNS and probably lower than NTP. But it apparently turns out to be a management conundrum. Specifically one group of people manage (network administrators) manage IP addresses, and another group (system administrators) manage operating systems. DHCP forces them to operate off the same data file. I wouldn't call Cisco a crap router at all, but it won't support what I need to do since there is no option to run my programs that generate the config data on there.

OK, so I'm going to move all our DHCP to a Linux box. Any suggestion for a deployment testing strategy that won't interfere with the existing DHCP?

Maybe not.

I'm trying to network boot a netbook on this LAN that has no PXE server, and only the router-based DHCP server. I see a request broadcast to port 67 which I believe is the DHCPDISCOVER. Then there is a packet back to port 68. It is then apparently ignored for some reason (perhaps because enough options to support a PXE network boot are not included) and another request is sent. This is repeated 4 times rapidly, followed by a pause, and another 4 times.

Perhaps if there are 2 DHCP servers, and one of them answers with enough of the right options to do a boot (e.g. file name of an image), it will do that. The next question is if it will do that even if that reply is not the first reply received.