How does a computer obtain an IP address via DHCP?

Question

How does the computer know which device on the network to query? How does the default gateway factor into this? Pretty much, what is the chain of events that occurs when a computer tries to obtain an IP address using DHCP?

The reason I ask is because I'm trying to figure out how to best set up a redundant DHCP server, in case the original fails for whatever reason.

Solution 1

It doesn't know what device to query. Thus it broadcasts its request to the entire subnet. The DHCP server is listening for a certain type of communication and when it hears that specific broadcast it begins the DHCP conversation with the device that broadcasted its request. Take a look at the DORA process for more information.

DORA stands for:

• D iscovery
• O ffer
• R equest
• A cknowledgement

As for the gateway, it can come into play only if it explicitly forwards DHCP traffic to another subnet. That feature is usually called DHCP Relay. Otherwise the gateway ignores the broadcast DHCP message just like it ignores every other broadcast message.

As for redundant DHCP servers, you'll want to keep them both on the same subnet and probably use the 80/20 rule. You can set up failover if you're using CentOS as your DHCP server.

Solution 2

DHCP is (generally) a broadcast protocol, so the client doesn't need to know anything about the network, it simply broadcasts a request.

DHCP servers on the network then see that request and respond to it.

Of course, it's much more complex than that, due to routing, and other network devices. The Wikipedia page is an excellent source.

And the relevant RFC covers the detail.

Solution 3

The reason I ask is because I'm trying to figure out how to best set up a redundant DHCP server, in case the original fails for whatever reason.

First, I laud your interest in learning more about the protocol. That is a good plan.

Second, I thank you for explaining your goal; I think it will help you get a good answer.

Finally, my answer:

For whichever DHCP server you choose to go with, there is likely a failover / redundancy configuration that permits you to set up a redundant DHCP server that can take over automatically (I believe Windows has such, and I know the ISC's DHCP server can). That would be my first choice, as it typically addresses issues with leases given out by the primary DHCP server before its failure, and because it recovers automatically and quickly.

Second choice would be to fully duplicate the configuration on another machine so that you can bring the other machine up manually in case of failure of the first. This isn't as optimal because you'll lose existing lease information and because of the implicit down-time between the first DHCP server failing and when you bring up the replacemnt.

Solution 4

Several steps are involved in obtaining an IP address from a dhcp server.

1. Discovery message, this message is broadcasted to search for a dchp server

2. The DHCP servers in the network replies with offer message.

3. DHCP request message is sent by the client by broadcasting..this message will inform all DHCP servers in the network, which offer was accepted by the client.

4. DHCP acknowledgement message is sent for the confirmation by the server.

View more solutions

Comments

[Nixphoe]

+1 DORA the dhcp explorer? I guess it would be more of a DORA the discover-er

[Wesley]

@Nixphoe Me gusta.

[crasic]

Here is a question, usually there is a broadcast address associated with every subnet, not knowing anything about the network how does the network card formulate the message so that the DHCP server (and any switches inbetween) gets it?

[MrGigu]

@crasic - every single subnet has a broadcast address. It's the last IP address in the range. So for 192.168.0.0/24, the broadcast address is 192.168.0.255

[crasic]

@Mark right, I get that. What I meant is how your computer (prior to obtaining an address via DHCP) broadcasts the address despite having no idea what subnet its on?

[MrGigu]

@crasic - right, in that case it broadcasts on 255.255.255.255

[Bigbio2002]

I see the point of the 80/20 rule... if server 80 fails, then there's still server 20 to give out IP addresses. But this doesn't provide any kind of support for an extended downtime, since eventually all of the clients will want to renew their lease, but with only 20% of the previous address range available. I like your suggestion of "real" redundancy, but using a second Windows machine would not be an option in my scenario (the hardware firewall would be the other DHCP server). I guess I could manually reconfigure server 20 to be server 100? ;)

[Bigbio2002]

Upvote for simplicity. It would be great if you could incoroporate this into the accepted answer

[Michael Hampton]

@Bigbio2002 It's your question. You get to decide which answer should be accepted.

[Damiano Verzulli]

@crasic: DHCP DISCOVER are sent to a broadcast MAC address, not a broadcast IP. It's a layer 2 broadcast address (ff:ff:ff:ff:ff:ff), not an IP 255.255.255.255. That's why common L2 switches can handle them, forwarding the ethernet broadcast datagram to ALL the switch ports (belonging to proper VLAN), hopefully reaching the DHCP server.

[Sumit Murari]

@DamianoVerzulli, it's sends to both "The DHCP client sends the DHCPDiscover, containing the MAC address of the DHCP client, to the limited broadcast IP address (255.255.255.255) and the MAC-level broadcast address." Ref: technet.microsoft.com/en-us/library/cc940466.aspx