We rely on DHCP to keep all of our devices working. In this video, you’ll learn about the DHCP process and how to assign IP addresses using a DHCP on a different broadcast domain.
In the early days of TCP/IP, everything dealing with the configuration of an IP address, a subnet mask, a default gateway, or any other IP parameters, was all a manual process. You had to visit every single workstation, or every single device on the network, and you had to manually configure all of these settings. This wasn’t bad when you had a handful of devices, but when you have hundreds, or even thousands of devices that have to be configured, visiting every single device is not a very practical way to provide this configuration.
So in October of 1993, we came up with an automated process for assigning these IP addresses, and we call this the Bootstrap Protocol, or BOOTP. Unfortunately, BOOTP didn’t configure everything that we needed in the IP configuration. There were still a number of parameters that had to be configured manually, but BOOTP didn’t know when someone left the network, or when an IP address might have been made available again.
So we updated BOOTP with a new protocol, called the Dynamic Host Configuration Protocol, or DHCP. We created DHCP in 1997, and we’ve made updates to the protocol throughout the years. Not only can DHCP provide these automated configurations that we need, but it can recognize when IP address leases may be over, and assign those IP addresses to other devices on the network.
Let’s go through the process that DHCP uses when someone connects to the network and needs an IP address configuration. In this network, we have Sam on one side, Jack is on the other. Sam is connected to a switch, and on that local network with the switch is a DHCP server. There’s also a router connecting sites together, and Jack is at this other site, connected to that router with a switch. Let’s take the configuration of Sam connecting to the network, and needing an IP address. This starts with Sam sending a DHCP Discover message from 0.0.0.0– because Sam does not have an IP address– and this is sent using UDP port 68 to 255.255.255.255. And if you recall, that is the broadcast address for a network. So every device that is on this local network will see this message that Sam is sending, including the DHCP server, and Sam is sending that broadcast to UDP port 67.
So Sam sends that message. Because it is a broadcast, that broadcast is sent to all devices on the network. A DHCP Discover message sent to a router that doesn’t have any DHCP services running would simply ignore that broadcast, but the broadcast does make it to the DHCP server that is on that local network. Now that the DHCP server has seen the Discover message from Sam, it wants to send a message back to Sam with some potential IP addresses that Sam can use. So the DHCP server sends a DHCP Offer message from its local IP address, which is 10.10.10.99, using UDP port 67, and it sends this to a destination address of 255.255.255.255.
The reason the DHCP server is sending this message out as a broadcast is because Sam doesn’t have an IP address yet, so there’s no way to unicast that particular message to Sam’s workstation. That all 1s broadcast is sent to UDP ports 68, and Sam is listening in to see if any of these broadcast messages are received, and that offer message is received by Sam’s device, because it was sent to all devices on the local network.
Sam is now received this offer a message from the DHCP server, and that offer message does have an IP address configuration that Sam can use. But before Sam can use that IP configuration, a DHCP Request message is sent from Sam’s workstation, which is 0.0.0.0, port 68 over UDP, to an all 1s broadcast of UDP port 67. And that message is sent to the server, saying that the IP address that we have received looks good, and we would like to use that IP address.
This final step is the DHCP server acknowledging that IP address is one that can be used, and can be configured on that local device. The DHCP server will send a DHCP Acknowledgment message from the DHCP server to an all 1s broadcast, over port UDP 68. At this point Sam’s workstation configures itself with the IP address that was originally sent in the Offer, and ultimately acknowledged in step four.
As we were going through that four-step process, you may have noticed that everything was being sent through broadcasts. And of course, broadcasts have no way to traverse routers. In a large enterprise environment, this becomes difficult to manage, because you don’t want to have to put individual DHCP servers on every local subnet. Instead, what we want to do is provide some way to have redundancy, so there are multiple DHCP servers to choose from, and we might also want to have multiple servers to handle the load of all of these devices wanting to configure themselves with IP addresses when they start up.
So we might want to put DHCP servers in key, critical places around the network, but still provide a way for all of the devices to access those servers, even though they’re still using broadcasts. To be able to do this, we use what’s called a DHCP Relay, or IP helper function, to be able to relay the message from the broadcast directly to a local DHCP server.
Let’s look at the same network configuration, but in this case, let’s look at Jack’s workstation. When Jack turns on his computer, he needs to have an IP address configured. But you’ll notice there are no local DHCP servers on Jack’s subnet, so simply sending broadcast to that subnet will not have any response, because those messages will never make it to the DHCP server that’s on a different IP subnet.
Instead, we’re going to configure this router with a special configuration setting called a DHCP Relay. You may also see this referred to as an IP Helper. We’re going to tell this router that if it ever receives a message for DHCP, to please transfer that message to the DHCP server that’s currently located at 10.10.10.99. And as you’ll notice, that is the IP address of the DHCP server that’s on the other broadcast domain.
From Jack’s perspective, the process is exactly the same as the one that Sam went through. Jack has no idea that there’s a relay in place. Jack is simply going to send the Discover message to an all 1s broadcast at UDP port 67. When that Discover message is received by the local router, the router recognizes that there is a DHCP Relay configured, and it changes the source address of the request to 10.10.30.1, which is the router, and the destination address to 10.10.10.99, which is the DHCP server. This means the router can send a direct message to the DHCP server without any worries of broadcast domains.
The DHCP server is then going to send a DHCP offer request, just as it did when it sent an offer to Sam, but in this case, the DHCP server is going to send the message to 10.10.30.1, because that’s the IP address that was received by the original Discover address. That message is then going to be sent back to the router, who of course recognizes the DHCP Relay configuration, and changes the IP address to be a broadcast for the local network, effectively making it exactly the same process that Sam went through, except now there’s a router in the middle that provides this additional relay function. The rest of the process continues exactly the same way it did for Sam, except now we have a relay in the middle to handle the request and the acknowledgment, so that Jack can then have his IP address configured by a DHCP server that sits on a different broadcast domain.