There are some important configuration options to use when configuring a DHCP server. In this video, you’ll learn about DHCP pools, scope properties, and the lease timers associated with DHCP.
Let’s say that you’ve been tasked with configuring a DHCP server, so you need to put all of the configuration settings into this server that other people can use to get an automatic IP address config. To be able to provide this information to your clients, you need to create a DHCP scope. The scope contains a number of different parameters.
Perhaps the most important will be the IP address range used by this particular section of the DHCP server, along with any addresses that you would not want to be assigned to individual workstations. You’ll also want to add the subnet mask for this network. You want to put in the duration of the lease, so you know exactly how long someone would have one of these IP addresses. And any other options that are important– for example, you may want to add DHCP servers, default gateway information, the details on an IP address for your Voice over IP gateways, or any other devices specific to the IP configuration of your clients.
This grouping of IP addresses is called a pool, and when a client needs an IP address, it sends a request to the DHCP server, and the DHCP server assigns an IP address from any one that may be available in this pool. A DHCP server may also have a scope of addresses. The scope is a single, contiguous pool of IP addresses that can be chosen for this automatic assignment process. Inside of the scope you can make exceptions. So there may be certain IP addresses that you would not assign to local clients.
Here’s what this would look like on a Windows Server that happens to have a DHCP server running inside of it. And you can see that I’ve created a single scope that is 165.245.44.0, and inside of that scope I would have an address pool. I would be able to see address leases, I can configure reservations, and I can look at any of the options specific to that scope.
Many DHCP servers are configured with a dynamic assignment, which means there’s a large pool of addresses, and when a client needs an IP address, that address is assigned from that pool. After the lease period is expired and that device does not renew the lease, then that IP address is added back to the available pool.
Many DHCP servers will also have an automatic assignment process, which means that once the IP address has been assigned to a workstation, that IP address will always be available, if possible. That way, if you leave and come back in a week, you may be assigned exactly the same IP address over and over and over again. This makes the assignment process a bit easier, although it does require additional overhead and a larger pool to be able to support all of these devices that may or may not currently be on the network.
Instead of randomly assigning an IP address from an available pool, we can also configure our DHCP server to assign a static IP address. This is especially useful if you have a server, and you would like that server to have exactly the same IP address every time it starts. You would add the MAC address of that server to the DHCP configuration, and assign it a matching IP address. Each time the file server makes a request to the DHCP server for an IP address, the MAC address is identified and exactly the same IP address and configuration is provided to that server every single time. You may see this process referred to as a static DHCP assignment, static DHCP, an address reservation or an IP reservation.
Here’s the address reservation process on my local DHCP server. This device is a router that has a DHCP server inside of it. And its starting IP address is 192.168.1.2 through an ending IP address of 192.168.1.254. I have taken two individual devices, though, and assigned an address reservation. You can see that 192.168.1.6 is assigned to a device called Prometheus, and there’s the MAC address of that device. I also have another server called Odyssey, and that device with that MAC address will always receive 192.168.1.9, thanks to this address reservation configuration.
As we mentioned earlier, the lease for the IP address that you receive on your workstation is only available for a certain amount of time, and unless you renew the lease, you have to give up that IP address at the end of the leasing process. The IP configuration, all of the IP settings, and the lease time are configured by the DHCP server administrator.
That lease time could be set to be very short, or the administrator can set it to be days or even weeks of time. If a device is rebooted, it does check back in with the DHCP server, and that lease may be reconfirmed during that process. You might also notice in the IP configuration of a device, that you could manually release the IP address back to the DHCP server as well, and then request a new IP address from that server.
This is especially useful if you have a laptop, you move that laptop to a new subnet, and you need to have the DHCP process occur again. You simply release the IP address that you currently have, and request the system to renew the IP address with the local DHCP server.
There are two important timers to know about during the DHCP leasing process. The first is a T1 timer. This is a timer that your client workstation uses to check back in with the DHCP server to automatically renew the lease that you currently have. By default, this is 50% of the lease time. There’s a second timer called a T2 timer. If the original DHCP server is down or it’s unavailable, the T2 timer will rebind with any available DHCP server. By default, the T2 timer is 87 and 1/2 of the lease time, or 7/8 of that available lease time.
Here’s how this would work. Let’s say we have a device that’s received a DHCP address the lease time has been configured on the DHCP server to be 8 days in length. This means that the T1 timer would occur after four days– that’s 50% of the time– and the T2 timer would occur after seven days, which is 87 and 1/2% of the time. So during the first four days of the lease is normal operation, and there’s no check back to the original DHCP server. After the first four days have occurred and that T1 timer is hit, the device checks back in with the DHCP server to renew the lease, and the clock starts again on the lease time.
Let’s– say in this scenario, though, that the original DHCP server is suddenly unavailable– it’s been turned off, or there’s been some type of outage– and we’re not able to renew after the T1 timer. We would wait all the way through to the seventh day– that is 7/8, or 87 and 1/2% of the time– to be able to rebind with any other available DHCP server on the network. If there is a DHCP server available during this rebinding process, then we have renewed the lease, and the timers are reset, and we go through the exact same process for the renewal after the T1 timer and the T2 timer.