How DHCP Works

So… How Does DHCP Work?

I’m glad you asked.  Lets not get to bogged down in the technical details, but rather take a high flying look at how DHCP works and do a few dives down to help with understanding.  The overall conceptual process for DHCP is strait forward:

  1. New computer on the network asks “what IP can I use on this network?”
  2. DHCP server sees this request and picks an IP for the computer to use
  3. DHCP server tells the computer the IP it should use as well as some additional information about how to use that IP.

Not much to it really.  For large or complex networks, DHCP gets more complicated than this, but by and large this is all that is happening when you connect a computer to a network using DHCP.  Now, lets dive in a look a little closer at each step

Computer Asks for IP Address

When a computer boots up it will ask the network it is connected to for an IP address.  It does this by sending a broadcast packet that will be copied to every computer on its section of the network.  This broadcast packet contains the computers “MAC” address and a request asking anyone that will answer, what IP address it should use.  A DHCP server will see this request and respond to it.

A quick note on how this works in small networks vs large networks.  In a small network, all the computers are normally all in the same network.  This includes the DHCP server.  So broadcast requests that client computers send out are heard by the DHCP server directly and responded to directly.

In a large network, computers are in many different network segments called subnets and often there is only one or two DHCP servers for the entire network.  What happens here is that a router for each subnet is configured to listen for the DHCP requests and forward them on to a DHCP server.  The router is called a “relay agent” or a “helper” in this situation.  When the DHCP server gets this forwarded request it looks at the IP of the router that forwarded the request to figure out what subnet the client is in and uses the part of its configuration for that subnet to decide what IP to assign to that client.

Picking an IP for a Computer

DHCP servers spend most of their time siting around patiently waiting for DHCP requests.  When it sees one, a server will take the MAC address in the request and run it through a couple checks, then assign it an IP.  The checks that it will do are:

  1. Have I already given this MAC address an IP?
  2. Does this MAC address have an IP reserved for it?
  3. What “pools” of IP’s do I have available to pull from for this MAC?
  4. I give up.

Have I already given this MAC address an IP?

Here, the server will check a list of IP assignments that it has already given out and see if the MAC address it received from the requester is in the list.  If it is, it will assign the same IP back to the computer that it had before.  An example where this happens a lot would be a laptop computer running on wireless.

Lets say a laptop computer has gotten an IP from the server already, then you put the computer to sleep by closing the lid for a few minutes.  When you wake the computer back up it doesn’t know if it is on the same network it was on before, so it will ask the DHCP server for an address again.  The server will see that it assigned an address to that computer 10 minutes ago and assign the same address to it again.

Does this MAC address have an IP reserved for it?

On a DHCP server you can normally “reserve” an IP address for a specific MAC address.   So whenever that MAC address shows up in a request for an IP the server will assign it the same IP every time.  Printers are a great example of when you would use this feature.

You can configure the DHCP server to always give a printer the same IP address, then configure the printer to use DHCP when it boots up.  Now the printer will get the same IP every time and you don’t have to statically configure information on the printer, so they are easier to maintain.

What “pools” of IP’s do I have available to pull from for this MAC?

Lastly, the DHCP server will now look for any pools of IP address that it has and just assign an IP from that pool to the computer.  A pool is just a range of IP’s you configure on the DHCP server for it to give to requesting computers.  When IP are assigned from a pool they will expire after a period of time if the computer using the IP doesn’t check back in.  If the IP expires it will assume the IP if free for anyone to use again and move it back into the pool to be assigned to another computer that comes along looking for an IP.

Then it gives up

If the MAC that is requesting an IP hasn’t already been assigned one, doesn’t have a reservation, and all the IP’s in the available pools have been used, then the server will basically give up and not assign an address to the computer, hoping another DHCP server will be able to do it.  Computer, you are on your own now.

DHCP Server Responds with IP and Additional Info (If Configured)

Output from command "ipconfig getpacket en1" to show some DHCP provided info

Example of some DHCP Options

If the DHCP server doesn’t have to resort to the “give up” step, it will pick an IP to assign to the requesting client and send it back to the client.  Along with an IP, the DHCP server can send additional information like a network mask, default gateway, a list of DNS servers, vendor specific information (used by VoIP and wireless systems), and more.  These extra pieces of information are called “options”.

The network mask, default gateway, and DNS options are used all the time.  Actually, DHCP is pretty useless without them because you only get 25% of the information you need to use the network if they aren’t used.  Vendor specific options are used far more infrequently.  They are used infrequently enough that some DHCP server software can’t even handle them (cough… Apple… cough, I’m looking at you).

At some point in the future I’ll talk more about vendor specific options.  Right now, it is enough to know that they exist and are used to send special configuration information to specialty equipment.  Like telling a VoIP phone the IP of the VoIP server, or a wireless access point (AP) the IP of the controller it should talk to.

Conclusion

DHCP isn’t rocket science but, as its name suggests, the language around the process can be full of acronyms and jargon.  When you pull all that jargon out it’s clear that DHCP is no more complex then a computer yelling out for an IP and an IP delivery man responding with nice shiny new IP to be used.

Did this article help you understand DHCP?  Sign up for our newsletter using the right side bar to get content like this sent directly to your inbox.  Also, let me know what you thought of this article in the comments.  I would love to hear your constructive feedback.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">