Lease Time One Hour with Windows DHCP Servers

Interesting question: Why does Windows DHCP server first assign me a lease for only one hour, and after that extend it to one day (or whatever was actually configured in the DHCP scope)?

First, let’s see that it really happens as described. Replicating the setup from my previous DHCP posts, I have here two VLANs: VLAN 60 is the client subnet and VLAN 41 is the subnet hosting the Windows Server 2022 DHCP servers. The servers are in failover configuration with load balancing enabled. There is also a Cisco CSR1000v router that is running DHCP relay to make DHCP work in the client subnet.

The DHCP servers have a DHCP scope configured for 192.168.60.0/24 network as follows:

• Start IP address: 192.168.60.100
• End IP address: 192.168.60.109
• Lease duration: 6 hours
• Router: 192.168.60.1
• DNS servers: 1.1.1.1 and 1.0.0.1

Let’s start the DHCP client on the testing host and see what it gets:

Jun 26 19:47:32 dhcptestclient dhclient[18886]: DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 7
Jun 26 19:47:32 dhcptestclient dhclient[18886]: DHCPOFFER of 192.168.60.100 from 192.168.60.1
Jun 26 19:47:32 dhcptestclient dhclient[18886]: DHCPREQUEST for 192.168.60.100 on ens192 to 255.255.255.255 port 67
Jun 26 19:47:32 dhcptestclient dhclient[18886]: DHCPACK of 192.168.60.100 from 192.168.60.1
Jun 26 19:47:32 dhcptestclient dhclient[18886]: bound to 192.168.60.100 -- renewal in 1500 seconds.

It got the IP address fine, but: “renewal in 1500 seconds”… that does not look like half of 6 hours, that’s just 25 minutes, or roughly half of one hour. Let’s see the lease file as well:

markku@dhcptestclient:~$ cat /var/lib/dhcp/dhclient.leases
lease {
  interface "ens192";
  fixed-address 192.168.60.100;
  option subnet-mask 255.255.255.0;
  option routers 192.168.60.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 1.1.1.1,1.0.0.1;
  option dhcp-server-identifier 10.0.41.30;
  option dhcp-renewal-time 1800;
  option dhcp-rebinding-time 3150;
  renew 1 2023/06/26 17:12:32;
  rebind 1 2023/06/26 17:40:02;
  expire 1 2023/06/26 17:47:32;
}

And how it looks like on the Windows DHCP server at 10.0.41.30:

dhcp-lease-time is 3600 seconds, or one hour (expiring at 20:47:32 local time), instead of the 6 hours that was configured in the DHCP servers.

Now let’s wait for the client to renew the lease as well, and here it happens:

Jun 26 20:12:32 dhcptestclient dhclient[18886]: DHCPREQUEST for 192.168.60.100 on ens192 to 10.0.41.30 port 67
Jun 26 20:12:32 dhcptestclient dhclient[18886]: DHCPACK of 192.168.60.100 from 10.0.41.30
Jun 26 20:12:32 dhcptestclient dhclient[18886]: bound to 192.168.60.100 -- renewal in 9562 seconds.

The client sent the renewal message directly to the DHCP server, got acknowledgement, and now the renewal will happen in 9562 seconds, or in about 2 hours and 40 minutes. The lease file on the client was updated accordingly:

markku@dhcptestclient:~$ cat /var/lib/dhcp/dhclient.leases
...
lease {
  interface "ens192";
  fixed-address 192.168.60.100;
  option subnet-mask 255.255.255.0;
  option routers 192.168.60.1;
  option dhcp-lease-time 21600;
  option dhcp-message-type 5;
  option domain-name-servers 1.1.1.1,1.0.0.1;
  option dhcp-server-identifier 10.0.41.30;
  option dhcp-renewal-time 10800;
  option dhcp-rebinding-time 18900;
  renew 1 2023/06/26 19:51:54;
  rebind 1 2023/06/26 22:27:32;
  expire 1 2023/06/26 23:12:32;
}

dhcp-lease-time 21600 = 6 hours.

So it’s true: the initial lease time was one hour, and then the lease renewal was accepted with the configured lease time (6 hours in this case).

Why is that?

The key point here is the failover configuration on the Windows DHCP servers. Apparently there isn’t much DHCP server documentation for the current Windows Server 2022, but the old DHCP failover documentation for Windows Server 2012 (and 2012 R2) is good enough here: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn338978(v=ws.11) (be sure to comment below if you know similar documentation for Windows Server 2022!)

In that documentation (in the DHCP Failover Settings page) there is a setting: Maximum Client Lead Time (MCLT):

The maximum amount of time that one server can extend a lease for a DHCP client beyond the time known by the partner server.

That doesn’t seem like a relevant configuration at first, but if you read the IETF DHCP Failover Protocol draft (that Windows DHCP server failover is based on) carefully, you’ll find that in the failover configuration the DHCP server first gives out the leases with lease duration of MCLT. (There is the logic described in the paper, it has everything to do with ensuring that whatever happens to the failover server cluster members or communication, the address leases are working properly without duplicate addresses as much as possible).

The default value of Maximum Client Lead Time in Windows DHCP server failover configuration is one hour:

So, that is the protocol and configuration that forces the first lease duration of an address to be one hour.

Note that you shouldn’t adjust the MCLT configuration unless you understand the consequences. There can (will) be unexpected consequences when you have lots of DHCP client activity and you change the MCLT configuration incorrectly, and there is a failure in the DHCP server cluster.

Now that we concluded that the (usually) one hour lease time is due to the DHCP server failover configuration, let’s see what happens when we delete all lease data from the client and also remove the failover configuration from the DHCP scope, and try again from the beginning:

Jun 26 20:45:53 dhcptestclient dhclient[18966]: DHCPDISCOVER on ens192 to 255.255.255.255 port 67 interval 6
Jun 26 20:45:53 dhcptestclient dhclient[18966]: DHCPOFFER of 192.168.60.100 from 192.168.60.1
Jun 26 20:45:53 dhcptestclient dhclient[18966]: DHCPREQUEST for 192.168.60.100 on ens192 to 255.255.255.255 port 67
Jun 26 20:45:53 dhcptestclient dhclient[18966]: DHCPACK of 192.168.60.100 from 192.168.60.1
Jun 26 20:45:53 dhcptestclient dhclient[18966]: bound to 192.168.60.100 -- renewal in 10247 seconds.

The lease file on the client:

markku@dhcptestclient:~$ cat /var/lib/dhcp/dhclient.leases
lease {
  interface "ens192";
  fixed-address 192.168.60.100;
  option subnet-mask 255.255.255.0;
  option routers 192.168.60.1;
  option dhcp-lease-time 21600;
  option dhcp-message-type 5;
  option domain-name-servers 1.1.1.1,1.0.0.1;
  option dhcp-server-identifier 10.0.41.30;
  option dhcp-renewal-time 10800;
  option dhcp-rebinding-time 18900;
  renew 1 2023/06/26 20:36:40;
  rebind 1 2023/06/26 23:00:53;
  expire 1 2023/06/26 23:45:53;
}

These confirm that without the DHCP failover configuration the server assigns the configured lease time (6 hours, or 21600 seconds) right from the beginning.

Windows DHCP server logs

In my previous post I showed how the ISC DHCP servers did with the leases according to the server logs, so here are the DHCP server logs on the Windows DHCP servers (from C:\Windows\System32\DHCP) when the failover configuration was used:

On the first server:

10,06/26/23,19:47:32,Assign,192.168.60.100,dhcptestclient,000C2967427A,
,6375501,0,,,,,,,,,0
11,06/26/23,20:12:32,Renew,192.168.60.100,dhcptestclient,000C2967427A,
,6375501,0,,,,,,,,,0
12,06/26/23,20:19:59,Release,192.168.60.100,dhcptestclient,000C2967427A,
,1771263953,0,,,,,,,,,0

On the second server:

36,06/26/23,19:47:32,Packet dropped because of Client ID hash mismatch or standby server.,192.168.60.0,,000C2967427A,,0,6,,,,,,,,,0

The logs showed clearly what happened: the first DHCP server assigned the lease to the client, and the second server ignored the request because the client ID hash value (as described in RFC 3074) indicated that the other server will serve the client.

If you want to see the DHCP packets from the failover example above, you can download the capture files here:

• DHCP client capture file
• DHCP server 1 capture file
• DHCP server 2 capture file