Regarding the dhcp lease time

[Simon Hobson]

Murali Krishna <muralikrishch at gmail.com> wrote:

> Shift in the system clock is part of the usecase(got this information from local team).

Then the usecase is broken. I cannot think of ANY valid reason for having the server time changing like that. I can think of some reasons for having a clock set incorrectly, but not on a server that's providing key services such as DHCP.
Also, from your earlier message it looks like the server time is changing - it's not just 5 years out, but switches between "correct" and off by 5 years and back again. Can you confirm if this is the case ?

> Also could you please help me understand how the lease value is calculated? How the lease value is calculated at the server end and provided to the client? How the client lease file is updated?
> 
> In the current scenario(in one of the execution) where the time stamp is updated to the older value as part of the use case
> Time stamp on the Server is:
> date:  date: Fri May 2 00:00:17 IST 2014
> 
> Time stamp on the client side is:
> date: Tue May 7 15:12:08 IST 2019
> 
> From the lease file(content) on the client side:
>   option dhcp-lease-time 158253456;
>   option dhcp-message-type 5;
>   option dhcp-server-identifier 169.254.64.12;
>   renew 5 2021/06/11 03:34:31;
>   rebind 2 2023/09/26 02:07:54;
>   expire 0 2024/05/12 01:02:36;
> 
> This dhcp-lease-time is matching approximately to the difference in the timestamps of server and the client. 

I will have to defer to someone with more knowledge of the internals - I don't know much about how the code works internally. In part, the answer will depend on the answer to the question above - does the server time change or is it permanently 5 years out ?
If the server time changes, then I could see where the issue could come from - but note that this is speculation without knowledge of how the code actually works.
When the time is correct, a short lease (says/weeks) would (at the time of writing this) have an end time in May or June of this year (2019) - and this would be stored internally in the server as well as written out to the leases file.
When the clock changes back by 5 years, the DHCP server now has leases with end times 5 years in the future - and so next time the client renews it is possible that it sends back a lease time based on this very long lease it already has, ignoring the requested lease length given by the client.
The client now receives a lease renewal with a 5 year life and stores it. Because it has a long lease, it has no reason to try and renew it before (in the example above) June 2021. There are some events (reboot, network interface goes down and comes back up, etc) that could trigger a renewal, but in normal operations, the client would not need to contact the server again for (in this case) another 2 years.

While writing this, I can see at least one serious problem that could arise. If the server clock is then reset to the correct time, there is a big difference between what the server thinks it has leased (a few days/weeks) and what the client thinks it has had leased to it (5 years). So in a few days/weeks time, the server will think that the lease has expired and that the address can now be given to another client - while the client still thinks it has years left on the lease. Depending on various factors (setting in use, client behaviour), this can cause a number of issues including clients that seemingly just don't get an acceptable offer or addresses that get marked as abandoned and which are no longer available for the server to hand out.


As an aside, I see another issue here ...
>   option dhcp-server-identifier 169.254.64.12;
I would not expect a DHCP server to be running on such an address.
Such link-local self-assigned addresses are not routable, and clients with an IP address given by a DHCP server will not be able to contact the server at that address. At renewal time, the clients will attempt to unicast renewal packets to the server and that will fail. The clients will eventually fall back to sending broadcast packets - but this delays renewal (reducing the time available to fix any problems) and increases DHCP traffic on the network.