Regarding the dhcp lease time

[Bob Harold]

The times in the DHCP packets should all be relative, so it should not
matter if the client and server clocks differ.

https://tools.ietf.org/html/rfc2131#section-3.3
"   As clients and servers may not have synchronized clocks, times are
   represented in DHCP messages as relative times, to be interpreted
   with respect to the client's local clock."

-- 
Bob Harold



On Mon, May 6, 2019 at 12:54 PM Sten Carlsen <stenc at s-carlsen.dk> wrote:

>
>
> On 06/05/2019 18.06, Murali Krishna wrote:
>
> Hi Carlsen,
>
> Time on the client side was not observed. Will try to get the time on
> server and the client when this is observed.
> Is this the expected behaviour of the dhcp that the server hands out a
> lease covering the time from the clients time to the current server time?
>
> I don't know. IIRC time from both ends is in the packets.
>
> I am sure someone else knows how the time is actually calculated, I was
> mostly guessing.
>
> Sten
>
>
> Thanks & Regards,
> Muralikrishna CH
> On Mon, May 6, 2019 at 9:07 PM Sten Carlsen <stenc at s-carlsen.dk> wrote:
>
>> Interesting.
>>
>> Seems the server hands out a lease covering the time from the client's
>> time to the current server time, essentially forever.
>>
>> This might have been done to compensate for the elapsed time from the
>> client sends the request until it is handled.
>>
>> One might think a cap on that time gap would be appropriate.
>>
>> I wonder if the client was ahead of the server time wise, would the lease
>> then be shorter -> negative -> no lease time?
>>
>> On 06/05/2019 16.54, Murali Krishna wrote:
>>
>> Hi,
>>
>> Before we tried to collect the packet captures. I would like to share
>> some information on the issue.
>> While analyzing the logs, it has been observed that the system time is
>> updated to very old time stamp(almost 5yrs back). From this point onwards
>> we are able to see that the huge lease value is getting updated in the
>> client lease file.
>>
>> 30566:Tue Apr 30 14:58:03 IST 2019
>>
>> 30804:Tue Apr 30 14:58:24 IST 2019
>>
>> 31042:Fri May  2 00:00:14 IST 2014
>>
>> 31280:Fri May  2 00:00:35 IST 2014
>>
>> 31531:Fri May  2 00:00:56 IST 2014
>>
>> …
>>
>> 33379:Fri May  2 00:03:23 IST 2014
>>
>> 33643:Fri May  2 00:03:44 IST 2014
>>
>> 33907:Fri May  2 00:04:05 IST 2014
>>
>> 34171:Fri May  2 00:04:26 IST 2014
>>
>> 34435:Fri May  2 00:04:47 IST 2014
>>
>> 34699:Tue Apr 30 15:03:39 IST 2019
>>
>> 34963:Tue Apr 30 15:04:00 IST 2019
>>
>>
>> Even though the system time is updated to the current time, there was no
>> update to the client lease file.  client lease file is updated to the
>> correct value only after we restarted the client.
>>
>>
>> Thanks & Regards,
>>
>> Muralikrishna CH
>>
>> On Tue, Apr 16, 2019 at 10:32 PM Simon Hobson <dhcp1 at thehobsons.co.uk>
>> wrote:
>>
>>> Sten Carlsen <stenc at s-carlsen.dk> wrote:
>>>
>>> > The server is configured with two times, max-lease-time and
>>> default-lease-time.
>>>
>>> Just to expend on that ...
>>> There is also min-lease-time.
>>>
>>> If the client specifies a desired lease time then the server will give
>>> that subject to min and max lease times.
>>> If the client does not ask for a specific lease time, then the default
>>> lease time is offered.
>>>
>>> As already mentioned, the first thing to do is look more closely at your
>>> packet captures. Check which devices the packets come from, and what's in
>>> them - particularly what options the client sends.
>>>
>>> --
>>
>> Thanks & Regards,
>> Muralikrishna CH
>>
>>
> Thanks & Regards,
> Muralikrishna CH
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20190506/dcf7e348/attachment-0001.html>