Imagine we have a network like in the picture. Six hosts on one layer 2 network, no VLANs. The network is supposed to be segmented into two subnets, with one DHCP server each. The DHCP servers have fixed IP addresses, so they know in which subnet they belong, obviously.

Then new clients get plugged in. They don't know anything about which subnet they're supposed to be in and send their DHCPDISCOVER to the Ethernet broadcast, so it goes to both DHCP servers. Both servers reply with an offer. Now here's my question: How does the client know, which DHCPOFFER he's supposed to accept?

DHCP situation

  • Compare this question and answers there. – Kamil Maciorowski Oct 26 '18 at 11:11
  • Here is another related question. – kasperd Oct 26 '18 at 14:22
  • 1
    "the ethernet broadcast" -- That's the IP broadcast address for the local network, not an Ethernet address. The initial DHCP DISCOVER messages also are very likely to use the Ethernet broadcast address ff:ff:ff:ff:ff:ff, but those really aren't the same thing. – ilkkachu Oct 26 '18 at 22:12

Simplest answer - first come first served.

If you had multiple VLANs and was on a different VLAN to - the broadcast wouldn't cross VLANs.

If the DHCP Server was on a separate VLAN to the clients, an iphelper on the routing interface between vlans would direct the broadcast onto the correct location.

In your scenario where you have 2 separate networks within the same VLAN (or lack thereof) serving up different subnets - its a race.

DHCP Serves up using the following transactions:

  1. DHCP Discovery (DHCPDISCOVER) - Client Broadcast - "Is there a DHCP Server out there?"
  2. DHCP Offer (DHCPOFFER) - Server to Client - "Yeah, I'm here and available!"
  3. DHCP Request (DHCPREQUEST) - Client to Server "Awesome, Can I have an address please?"
  4. DHCP Acknowledgement (DHCPACK) - Server to client "Sure, here's an IP, a mask, a gateway, some DNS/WINS Servers, a Time Server, and all the other stuff configured for your scope"

All of this happens on UDP Ports 67 for the server and 68 for the client.

As soon as Step 2 is reached - the client will stop "listening" to other DHCP Servers responses - its happy dealing with the first Server to give it some attention.

As a side note - there is actually a well known series of DoS (Denial of Service) attacks which abuse this right. An attacker plugs in a device which responds and sends out DHCPOFFER packets and then doesn't send DHCPACK out when asked... over and over and over again. There is also another DoS attack where "fake" DHCP Servers offer out addresses that can't be routed or that conflict with other IPs it's sniffed to mess with networks.

  • 16
    And therefore the short answer to "But then how do I run multiple subnets on a single Layer-2 segment?" is "You don't." (Yes, there are ways, but it's not something you should generally do. One layer-2 domain = one subnet.) – user1686 Oct 26 '18 at 9:09
  • Thank you guys, that really clicked with me. I always wondered how this would be possible, but it simply isn't. So the take away is: Have a router / layer 3 switch between subnets or segment with VLANs, am I right? – Michael Niemand Oct 26 '18 at 9:13
  • 4
    In general, yes, you need either VLANs or physical segmentation. Sharing a L2 domain would be doable only if both of your DHCP servers were restricted to handling "known" clients (e.g. by list of 'static leases' with allowed MAC addresses). – user1686 Oct 26 '18 at 10:40
  • 3
    I think you could give each DHCP server a whitelist of MAC addresses and control which client gets an address from which server that way. – Darren Oct 26 '18 at 12:20
  • @grawity, you can easily run multiple IP subnets on the same layer-2 segment, if the subnets are equal, and you don't care which client gets an address from which subnet. You just have one DHCP server that gives addresses from both blocks, and one router that acts as a gateway for both blocks (with an address in each). Done. Saying just "you don't" is plain wrong. – ilkkachu Oct 26 '18 at 22:14

The existing answer from @Fazer87 is broadly correct in practice and I recommend upvoting and accepting it. This answer explores a minor detail a little more precisely.

Both DHCP servers may respond with a DHCPOffer message.

A DHCP client may accept them on a "first come, first serve" basis. However, it is not required to take that approach.

RFC2131 specifies:

The client receives one or more DHCPOFFER messages from one or more servers. The client may choose to wait for multiple responses. The client chooses one server from which to request configuration parameters, based on the configuration parameters offered in the DHCPOFFER messages.

So, if second DHCP server offered a longer IP address reservation, or offered a time-server where the other didn't, or maybe had a custom field that the client had been programmed to prefer, it may accept the second offer.

Typically, a "first come, first served" approach is going to get you the offer that hasn't been through several hops across devices (BOOTP rebroadcasts) so it is a good protocol to follow if you have no reason to care.

I was on one project where a custom device would prefer a DHCPOffer that included a TFTP server where updated firmware could be found.

  • ...or if one server offered an address that the client had already used before and wanted to keep – ilkkachu Oct 26 '18 at 22:16
  • @ilkkachu: Yes, in theory, but there are better mechanisms for this (both renewing a reservation before it expires with the old DHCP server, or sending out a DHCPDiscovery requesting the old IP address) so it is unlikely to be useful in practice. – Oddthinking Oct 27 '18 at 1:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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