mjhjmtu

I am not completely oblivious when it comes to networks but here is something I can't wrap my head around.

Imagine we have a network like in the picture. 6 hosts on one layer 2 network, no VLANs. The network is supposed to be segmented into 2 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 know nothing about which subnet they're supposed to be in and send their DHCPDISCOVER to the ethernet broadcast 255.255.255.255, 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 it is supposed to accept?

Simplest answer - first come first served.

If you had multiple VLANs and 10.10.10.0/24 was on a different VLAN to 10.10.20.0/24 - 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.

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.