We rely on DHCP for the automatic configuration of our network devices. In this video, you’ll learn about the four steps of the DHCP process and how a DHCP relay can provide flexibility with DHCP services.
<< Previous Video: DNS Record Types Next: Configuring DHCP >>
We’ve now become very accustomed to having our IPv4 devices automatically configure themselves with an IP address when we connect to the network, but it didn’t always used to work this way. It used to be a very manual process, where the network administrator would have to visit every device and manually configure the IP address, the subnet mask, the default gateway, DNS information, and anything else necessary for that IP configuration. This was obviously a lot of additional overhead for network administrators, so we created the BOOTP protocol.
BOOTP is the bootstrap protocol that allowed us to automatically configure these settings without having to visit and manually input this into every single device, but boot we didn’t configure everything. A number of manual configurations were still needed, and BOOTP didn’t have a mechanism to understand when certain IP addresses may have become available again after being leased. So we created a successor to BOOTP called DHCP, or dynamic host configuration protocol. This is the primary and automatic configuration protocol for IP version 4, and if you’re connecting to an IP version 4 network and automatically receiving an IP address, it’s because there’s a DHCP server on that network.
Let’s step through every process of the DHCP leasing. We have a network here that has Sam. There’s a switch in a subnet associated with Sam’s machine, and there’s a DHCP server on that subnet, as well. There’s a router that connects over a wide area network linked to another network, where Jack has a laptop computer, but notice there’s no DHCP server on that particular subnet.
Let’s focus on Sam’s machine. Sam starts her laptop. The first step is a DHCP discover message. Currently Sam does not have an IP address. She’s just turned on her laptop, so a broadcast is sent across the network to UDP port 67.
That broadcast is going to be a DHCP discover message. So as that packet goes out, it will be broadcast to all other devices on the subnet, and this subnet certainly has a DHCP server associated with it. Because this is a broadcast, it goes as far as the router, and then it does not go any further than that router. The router, of course, will stop all broadcasts from going through it, but this message did make it to this DHCP server, and you’ll notice that the next step will be this DHCP server is going to offer Sam an IP address. Sam obviously doesn’t have an IP address yet, so this DHCP server needs to send this offer over an IP broadcast to UDP port 68.
Again, as a broadcast it goes out to all devices on the subnet, but fortunately, again, the router will stop that broadcast from going any farther on the network, and that broadcast was received by Sam’s workstation. There may be more than one DHCP server on the network, and Sam may have received multiple offers. So Sam will pick one of those offers and send back a DHCP request, again, to a broadcast address through UDP port 67. That broadcast goes to everything on the network. It’s stopped by the router, but is made to the DHCP server, and now that server sees that Sam has indeed requested that original offer that was made.
The last step then is for that DHCP server to send an acknowledgment saying that Sam has now leased that particular IP address and can configure it for her laptop. Again, this will be sent from this DHCP server to an IP broadcast using UDP port 68. And when Sam’s laptop receives that acknowledgment, the DHCP client in her laptop will automatically configure it with the correct IP address that was provided in the acknowledgment.
If you’re trying to implement DHCP in a large organization, there are a number of challenges you have to deal with. As we’ve seen in the previous example, routers will stop these broadcasts from going through the network. So we need some way to be able to have centralized DHCP servers, but still able to maintain the DHCP requests for all of the different subnets on our network. We also may want to have redundancy with our DHCP servers. These are extremely important services, so we may want to have two or more of these servers running simultaneously.
You may also want to have a more scalable distribution of these DHCP servers. Some might be in the core of your network, but you also might want to have DHCP servers provided at remote locations, and it’s very common to have these DHCP servers located on different IP subnets. But we know that routers will stop these broadcasts. Fortunately, many routers allow us to configure what’s known as a DHCP relay. You may also hear this referred to as an IP helper, that will take the broadcast that normally would be stopped by the router and convert it to a unicast that can then be sent to the DHCP server.
Let’s see how we can use this DHCP relay or IP helper function to allow Jack to receive a DHCP address. We notice from that original network configuration that the only DHCP server on this network is over on the same subnet that Sam happens to be on, but there are a number of routers between Jack and that DHCP server. So we’re going to configure that first router that’s closest to Jack with a DHCP relay IP address, and we’ll tell it that the DHCP server that will be provided for this subnet is located at 10.10.99, which is also the IP address of this DHCP server.
The first step for DHCP is the DHCP discover. Jack is going to send a broadcast to UDP port 67, and as that broadcast reaches that IP helper or DHCP relay address, this router realizes that it needs to convert this broadcast to a unicast. So it changes the source IP address to be the router, and it modifies the destination address to instead of being a broadcast, to be exactly the IP address that we originally configured as the DHCP relay address inside of this router.
This DHCP relay also allows us to take the unicast being sent back in response and convert those back to broadcast. The DHCP relay is going to receive the DHCP servers offer, and it’s being sent to that directed IP address of 10.10.30.1 that was configured in that earlier example. When it reaches that address, the router understands that this needs to be a broadcast. It changes the destination address to that all one’s broadcast and sends that message out to the network where it will be received by Jack. This DHCP relay will continue to make these changes throughout the DHCP process, and eventually it will complete and Jack will have an IP address that was provided by the DHCP server that exists on a different IP subnet.
On larger networks, the management of DHCP and all of the available IP address pulls can be challenging. In those cases, you may want to implement IP address management, or IPAM. This allows you to manage all of your IP addressing, your DHCP servers, and you can track and see exactly how much of which IP address pools are being used. You know what IP addresses are being used during what part of the day, and you can see all of the user to IP address mappings.
From a DHCP management perspective, you can understand exactly what type of DHCP reservations are configured. You can see how much of your IP pools are in use. You could see if there’s any problems or shortages, so that you’re always on top of knowing exactly what’s happening with your DHCP services, and because many organizations are supporting both the DHCP for IP version 4 and IP version 6, the single console can give you a perspective across both of those protocols.