We rely on the Dynamic Host Configuration Protocol to automatically assign addresses to our network devices. In this video, you’ll learn about the DHCP process and how DHCP relay can be used to design a more efficient DHCP process.
On our modern networks, we’ve become so accustomed to simply turning on our systems and we’re able to communicate with other devices on our local network or browse the internet. But it wasn’t always this easy. We used to manually configure all of our IPv4 configuration settings. The IP address, the subnet mask, the DNS settings and everything else associated with TCPIP was all configured manually on every device.
In order to scale this process, we created a new protocol that would do all of this for us automatically. This was called the bootstrap protocol, or BOOTP. But BOOTP didn’t configure everything automatically, and there were a number of enhancements that we would like to make to the protocol. For example, if someone left the network, it would be nice if this protocol recognized that that IP address was now available.
So we created a newer version of bootp called DHCP, or the Dynamic Host Configuration Protocol. DHCP is the protocol we use today to provide these automatic address configurations for all of the devices on our network. The process for defining these IP addresses automatically follows four different steps that we’re going to call DORA. D-O-R-A.
The D stands for discover, where there is a discovery process where you find the DHCP servers that are on your network. The next step is the offer phase where we get an offer from a DHCP server. The third step is the request process where we request one of the offered IP addresses. And then lastly, we have the acknowledgment phase where we tell the DHCP server that we have received that configuration and are using that particular IP address.
Let’s step through all four of those phases from the perspective of this network diagram. On this diagram we have, Sam, that is just connected her laptop to the network and she needs to receive an IP address. On her local subnet, you can see there is a single DHCP server and there are other devices on this network that we’re simply not showing in this particular diagram. There’s also a router. And this router is connected across a wide area network to another router where there’s a separate switch and another workstation that is owned by Jack.
Let’s focus on the process that Sam is going to use to obtain an IP address. This first step is the discover step. And in this step, Sam’s workstation is going to send a DHCP discover packet. It’s going to be sent from an IP address of 0.0.0.0 because Sam’s workstation currently does not have an IP address. And this packet is going to be sent in an IP broadcast, which means it’s going to be sent to 255.255.255.255.
This is sent as a broadcast so that every device on the subnet will see this DHCP request. And if the device happens to be one or more DHCP servers, those devices will be able to respond back. You’ll also notice that this request is sent using UDP port 68 on Sam’s workstation and the broadcast is sent to UDP port 67. This packet is sent from Sam’s laptop. And because it’s a broadcast, it’s sent to all devices on this local subnet.
The DHCP server will see that broadcast and it will send a DHCP offer, which is step two of the DHCP process. This DHCP server has an IP address of 10.10.10.99. And it will send this with a source port number of UDP port 67. Notice that the DHCP server is going to send this as a broadcast.
Send it to 255.255.255.255 and it’s going to send this to a destination port number of UDP 68. This is obviously being sent as a broadcast because Sam’s workstation currently does not have an IP address. And the only way that Sam’s device would see this packet is if it’s sent to all devices on the subnet.
This DHCP offer will be sent from the DHCP server and broadcast to all devices on the subnet. If there were multiple DHCP servers on this network, Sam could potentially receive more than one offer from a DHCP server. So in step three, Sam’s device is going to choose one of those offers and send a DHCP request to that particular DHCP server.
This request is obviously coming from 0.0.0.0 because Sam’s workstation still does not have an IP address. It is sourced from UDP port 68. And the destination is going to be 255.255.255.255. Another all ones broadcast, and it’s being sent to a destination port number of UDP port 67. This traffic flow is very similar to that first discover traffic flow where all of the packets are broadcast to all devices on this local subnet.
And the last step is step four or the acknowledgment. This is sent from the DHCP server back to this device, acknowledging that it has received that request. The acknowledgment is sent from the DHCP server. In this case, 10.10.10.99 with a source port number of UDP port 67. And again, it is sent to a broadcast address. 255.255.255.255 with a destination port number of UDP port 68. And again, this will go to all devices on the subnet, but obviously the only person waiting for that acknowledgment would be Sam’s device.
Now that Sam’s laptop has received the acknowledgment from the DHCP server, it can now configure all of the IP settings automatically for Sam’s laptop. As you may have noticed from that network map and the different phases that we went through with DHCP, there is a significant limitation associated with the DHCP process. And that is the broadcast that is being sent by the different devices.
Broadcasts, of course, are only transmitted to your local subnet. And none of those broadcast frames will traverse a router. This becomes a challenge for an enterprise network where you’d like to have redundant DHCP servers and ideally have those DHCP servers distributed across different parts of the network.
Fortunately, there is a way to implement DHCP in this environment by using some additional features of your router. We also might want to centralize these DHCP servers instead of having separate individual DHCP servers that are scattered across every remote site that we might have. Fortunately, many routers support a way to enable DHCP across these different subnets even though DHCP uses broadcast to communicate.
We refer to this router functionality as a DHCP Helper or a DHCP Relay. This will allow you to send DHCP traffic to another subnet even though it’s being sent originally as a broadcast. We would first configure a router with a DHCP relay configuration. And in that configuration of the router, we would specify that there is a DHCP server located at 10.10.10.99. And that is our original DHCP server that we were working with earlier.
In this scenario, Jack would like to receive a DHCP address, but as you can see there is no DHCP server on Jack’s local subnet. Jack’s laptop doesn’t know this however, and it will simply send the normal DHCP discover message out to everyone on this local subnet. When that broadcast is received by the router configured with DHCP relay, it will look at its configuration and realize there is a DHCP server at 10.10.10.99 and it will relay that information to the DHCP server.
It changes the source IP address to the IP address of the router. In this case, 10.10.31.1. And it changes the destination address to the IP address of the DHCP server. It effectively takes what was a broadcast and turns it into a unicast communication. This packet can now be sent across the network to a DHCP server that’s located on a different subnet.
The offer process works exactly the same, but in reverse. The offer leaves the DHCP server and is directed with unicast to the router’s IP address at 10.10.30.1. At this point, the relay modifies this back to a broadcast and is sent to the local subnet with an all ones broadcast. This process repeats for the last two phases of the DHCP process. And that allows Jack’s workstation to receive an IP address, even though the DHCP server may be on a completely different IP subnet.