Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have to research the possibility of having 2 DHCP servers on the same network (e.g. the network of our university), each sending their messages to their own nodes without interference of the other one. I'm not talking about 2 DHCP servers where one is a back-up for the other one; just two servers, who have their own set of nodes to which they have to send their messages to. We have relatively little knowledge of this matter and we were told this is not easily done.

Does someone know how this could be made possible of can someone guide us to the right direction to look for?

EDIT (the collegue):

What we try to achieve is the following: We want to use OMF ( to test some nodes in a netwerk. OMF setups the nodes (clients) via DHCP and PXE. The normal network layout for OMF is to have a separate testbed net that are attached to one router that serves as DHCP server.

We are interested in deploying some testbed nodes within the normal network topology. So say that now 15 computers in a row are attached to one router and get an address in the X.Y.Z.1-X.Y.Z-200 range. What we want to do is add 5 computers on the same router that get their address (and PXE information) from another DHCP server.

Hardcoding the MAC addresses from the large (existing) network is not a solution, it is not feasible in our case.

share|improve this question
why, give us a valid reason to implement this? – tony roth Dec 3 '11 at 17:33
why indeed. academia o_O – Sirex Dec 3 '11 at 17:38
Define what "sending their messages to their own nodes without interference of the other one" means? – joeqwerty Dec 3 '11 at 19:53
I have a strong suspicion that the answer to this question is "Your instructor is an idiot", but I suspect we need to hear clarification of the point joeqwerty asks in order to be sure, or for that matter, to give you a good answer. – RobM Dec 3 '11 at 22:23
You either use VLANs or Split-Scope DHCP. The other options lead to madness. – kce Dec 4 '11 at 11:53

It's possible to have 2 DHCP servers with different ranges operating on the same subnet. In this case the first one to respond (or rather have its response reach the client) is the one that is used for that client, and no address collisions occur (due to the servers) as neither server will offer an address that the other one will.

However, at least in the case of ISC's dhcp daemon (this the one most commonly used by Linux) it would be better to look into DHCP failover. Here both servers operate with the same ranges and coordinate address allocation between themselves. This allows a larger range can be available if one of the servers go down, and means the lease information is not lost, reducing collisions when the failed server is brought back in operation.

If you need different machines to receive different information, please look at pool in conjunction with host and/or group for ISC or the equivalents for whichever dhcp server you are using.

You should not have two groups (different from groups) trying to manage DHCP on the same subnet.

Without knowing what you're trying to accomplish and what you can and/or are trying to use, this is as clear as I can be.

short answer: Yes, but it's only an optimal solution to any problem.

share|improve this answer
+1: "DHCP servers with different ranges operating on the same subnet." , for the only sane way to do this. – kce Dec 4 '11 at 11:49

Define "same network". Based on your question description, you mean "same physical hardware (i.e. switches), but not the same subnets". It also seems from your question that the 2 subnets should not be able to communicate with each other.

If that's the case, then you'd do it with VLANs, so the traffic does not overlap. You would need a VLAN capable switch (or switches), and just associate "Network A" with VLAN X and "Network B" with VLAN Y.

share|improve this answer

Yes, this is possible.

I would use the HCP mode for both servers - fixed MAC-addresses to IP pairs (for "their" clients).

Both servers should not send NACKs for unkown client - the other one could know about that one.

Use these two directives in each server:

not authoritative; ignore unknown-clients;

share|improve this answer
It is not feasible in our case to bind each MAC address (we are talking about the network of our university, so rather a large set of nodes :)) – atobi Dec 4 '11 at 11:40
So you need a way to differentiate - what will be your criterion? You could try "nearest ist the first to answer" - but that may not work in some cases. – Nils Dec 4 '11 at 20:35

Your further explanation helps clarify what you're doing, but I believe the answer is now "yeah, that ain't going to work".

DHCP servers don't send "messages" to "their nodes", they are essentially a very simple process that tries to reply as fast as possible to a broadcast request for an IP address. If you don't/can't exclude some clients from some of the DHCP servers then there's not a lot you can do. If they're on the same physical and logical network then clients will take an IP address from whichever DHCP server replies to their request first.

Your best option is to isolate your test machines and server from the main LAN, either physically with a separate switch or logically with VLANs.

share|improve this answer

I do this and it is very helpful for a spread out network where you want to create simple rules that apply to different ranges of IP (because I know where they are located).

Route ports 67/68 to the local network node and map the port so those port requests don't head over to the network node you want to isolate. Basically, keep port 67/68 requests limited to your node and the DHCP in that node will be the one to answer.

I've found this nice to do when I want to create a bandwidth control over a certain area of users and not apply the same rule to others.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.