Regarding the dhcp lease time

[Murali Krishna]

Hi,

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Sten Carlsen]

On 15/04/2019 18.48, Murali Krishna wrote:

Hi,

The server is configured with two times, max-lease-time and default-lease-time. It will send those times to the client, in this case it looks like the server is configured to send very long times (4.8 years). It is up to the client when it wants to renew the lease, the 3600s is clearly within the bounds of what it is given.

If you want shorter lease times, the server needs to be configured to hand out those times instead.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

Hi,

Thanks for your inputs.

I quickly checked in my system.

From "/etc/dhcpd.conf", i could clearly see that 600 is set to both max and default. This output is from server side.

    max-lease-time 600;

    default-lease-time 600;

On the client side, "/etc/dhclient.conf" says:

send dhcp-lease-time 3600;

Thanks & Regards,

Muralikrishna CH

On Tue, Apr 16, 2019 at 12:25 AM Sten Carlsen <[hidden email]> wrote:

On 15/04/2019 18.48, Murali Krishna wrote:

Hi,

The server is configured with two times, max-lease-time and default-lease-time. It will send those times to the client, in this case it looks like the server is configured to send very long times (4.8 years). It is up to the client when it wants to renew the lease, the 3600s is clearly within the bounds of what it is given.

If you want shorter lease times, the server needs to be configured to hand out those times instead.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Sten Carlsen]

On 16/04/2019 06.10, Murali Krishna wrote:

Hi,

Thanks for your inputs.

I quickly checked in my system.

From "/etc/dhcpd.conf", i could clearly see that 600 is set to both max and default. This output is from server side.

    max-lease-time 600;

    default-lease-time 600;

In this case the only other explanation I can think of is a rogue server on your network. This would require a closer study of the actual packet capture.

On the client side, "/etc/dhclient.conf" says:

send dhcp-lease-time 3600;

Thanks & Regards,

Muralikrishna CH

On Tue, Apr 16, 2019 at 12:25 AM Sten Carlsen <[hidden email]> wrote:

On 15/04/2019 18.48, Murali Krishna wrote:

Hi,

The server is configured with two times, max-lease-time and default-lease-time. It will send those times to the client, in this case it looks like the server is configured to send very long times (4.8 years). It is up to the client when it wants to renew the lease, the 3600s is clearly within the bounds of what it is given.

If you want shorter lease times, the server needs to be configured to hand out those times instead.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

Hi,

Could you please confirm, Having two different versions on server and client side can lead to these kind of issues? or does this impact the system?

Thanks & Regards,

Muralikrishna CH

On Tue, Apr 16, 2019 at 12:47 PM Sten Carlsen <[hidden email]> wrote:

On 16/04/2019 06.10, Murali Krishna wrote:

Hi,

Thanks for your inputs.

I quickly checked in my system.

From "/etc/dhcpd.conf", i could clearly see that 600 is set to both max and default. This output is from server side.

    max-lease-time 600;

    default-lease-time 600;

In this case the only other explanation I can think of is a rogue server on your network. This would require a closer study of the actual packet capture.

On the client side, "/etc/dhclient.conf" says:

send dhcp-lease-time 3600;

Thanks & Regards,

Muralikrishna CH

On Tue, Apr 16, 2019 at 12:25 AM Sten Carlsen <[hidden email]> wrote:

On 15/04/2019 18.48, Murali Krishna wrote:

Hi,

The server is configured with two times, max-lease-time and default-lease-time. It will send those times to the client, in this case it looks like the server is configured to send very long times (4.8 years). It is up to the client when it wants to renew the lease, the 3600s is clearly within the bounds of what it is given.

If you want shorter lease times, the server needs to be configured to hand out those times instead.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Niall O'Reilly]

On 16 Apr 2019, at 9:08, Murali Krishna wrote:

> Could you please confirm, Having two different versions on server and
> client side can lead to these kind of issues? or does this impact the
> system?

The answer to each of these questions is, "No."

As Sten Carlsen suggested, you need to take a more detailed look at your
PCAP data,
and determine the origin and destination of each packet.

Best regards,
Niall O'Reilly

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Sten Carlsen <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

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 <[hidden email]> wrote:

Sten Carlsen <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Sten Carlsen]

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 <[hidden email]> wrote:

Sten Carlsen <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

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?

Thanks & Regards,

Muralikrishna CH

On Mon, May 6, 2019 at 9:07 PM Sten Carlsen <[hidden email]> 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 <[hidden email]> wrote:

Sten Carlsen <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Sten Carlsen]

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 <[hidden email]> 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 <[hidden email]> wrote:

Sten Carlsen <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[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."

On Mon, May 6, 2019 at 12:54 PM Sten Carlsen <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

Sten Carlsen <[hidden email]> 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.

-- 

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Murali Krishna <[hidden email]> wrote:

> While analyzing the logs, it has been observed that the system time is updated to very old time stamp(almost 5yrs back).

On the server ? If this is the case, then the DHCP service is not your problem. You need to find out what's going on with the system clock - until you do that then it's pointless trying to solve other problems.

On the client ? In this case, then I can only *guess* that the client service is seeing the time difference between the system clock and the end time/date it has stored, and updating something accordingly.

It might help if you showed the actual log entries, not just the timestamps. In any case, the cause of the clock changing should be the focus of your investigations.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

Hi,

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

Also collected the pcap file by reproducing the issue.   I have taken the screenshot of the pcap file where it clearly mentions about the huge lease value.

Im not very sure whether it is ok to attach the complete pcap file to the discussion.

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. 

Many thanks in advance.

Thanks & Regards,

Muralikrishna CH

On Tue, May 7, 2019 at 1:57 AM Simon Hobson <[hidden email]> wrote:

Murali Krishna <[hidden email]> wrote:

> While analyzing the logs, it has been observed that the system time is updated to very old time stamp(almost 5yrs back).

On the server ? If this is the case, then the DHCP service is not your problem. You need to find out what's going on with the system clock - until you do that then it's pointless trying to solve other problems.

On the client ? In this case, then I can only *guess* that the client service is seeing the time difference between the system clock and the end time/date it has stored, and updating something accordingly.

It might help if you showed the actual log entries, not just the timestamps. In any case, the cause of the clock changing should be the focus of your investigations.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson-2]

Murali Krishna <[hidden email]> 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.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Just to add, AFAIR lease times in the packets on the wires are just durations in seconds. So if both server and client clocks are stable then any offset doesn't matter at all - each will work relative to it's own time.

It's the change in server clock that's the problem. *Changing* the time on a server (apart from simple correction to keep it accurate) is generally "a bad thing" and can break all sorts of things.


As an aside, I once worked with an OS (Apollo Domain) where (IIRC) file inodes were a combination of the machine's MAC address and clock time at the point of file creation. Changing a network card or moving a hard disk between nodes meant running a program to change the MAC address part of all inodes, but setting the clock backwards was a real "just don't do it" thing due to the problems it could create with duplicate inode numbers.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Rob Janssen]

Simon Hobson wrote:
> Murali Krishna <[hidden email]> 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 ?
>

Is it really a "usecase"?  Or is it merely a "testcase"?
I have seen such postings many times on NTP lists and groups, where a "local team" wants to validate the operation of the NTP service and decides to write a testplan similar to this:

- setup an isolated local network with a client and a server
- start them and observe that the client locks to the time of the server
- manually change the clock of the client (or the server) by several years using methods external to the NTP server or client
- observe that the client synchronizes to the server again, note how long it takes.

When that does not work out, they come and ask why.
It can be asked why they would want to use such functionality and of course there never is a clear answer, the usage is not really in the daily usecase, but they had written that in their testplan, probably got it approved, now they are running it
and when it does not work they will have to amend the testplan to be able to pass the software, which of course will raise eyebrows.

Having a LAN address of 169.254.x.x is not that uncommon in such test environments.

Rob

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Rob Janssen <[hidden email]> wrote:

> I have seen such postings many times on NTP lists and groups, where a "local team" wants to validate the operation of the NTP service and decides to write a testplan similar to this:
>
> - setup an isolated local network with a client and a server
> ...
> - manually change the clock of the client (or the server) by several years ...
>
> When that does not work out, they come and ask why.

Or come here and ask why the DHCP service is "broken" !


> Having a LAN address of 169.254.x.x is not that uncommon in such test environments.

Which is still not valid for a DHCP server - common or not.


We'll just have to wait for the OP to come back with an alternative narrative ;-)

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

Hi,

I agree to your comments that rather than the usecase this is a testcase. 

The same test case is working without any issues, when the below versions are available on server and client respectively.

version available on server and client: 4.2.1-P1

But the same testcase is not working when we have the below versions.

version on server: 4.3.6

version on client: 4.2.1-P1

Apart from that, the other clarification which i would like to get clarified from the experts is that how the server acts to the DHCP requests from the clients in a situation where the time stamps are completely different. From the conf file server should acknowledge the respective seconds of the leasetime(as mentioned in conf file) irrespective of the timestamps. This is not happening in this scenario where server is offering a huge lease value. 

In the current scenario client requested for the respective lease for the time duration as mentioned in the conf file. 

Here is the sequence of flow it happened:

1. Client initiates DHCP Request for 3600s(1hr)

2. Server acknowledges(DHCP Ack) with lease time:(158253440s) 1831 days, 15 hours, 17 minutes, 20 seconds

How the server is calculating the lease time which is not the one defined as per the conf file.

Thanks & Regards,

Muralikrishna

On Fri, May 10, 2019 at 9:55 PM Simon Hobson <[hidden email]> wrote:

Rob Janssen <[hidden email]> wrote:

> I have seen such postings many times on NTP lists and groups, where a "local team" wants to validate the operation of the NTP service and decides to write a testplan similar to this:
>
> - setup an isolated local network with a client and a server
> ...
> - manually change the clock of the client (or the server) by several years ...
>
> When that does not work out, they come and ask why.

Or come here and ask why the DHCP service is "broken" !


> Having a LAN address of 169.254.x.x is not that uncommon in such test environments.

Which is still not valid for a DHCP server - common or not.


We'll just have to wait for the OP to come back with an alternative narrative ;-)

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Niall O'Reilly]

On 13 May 2019, at 16:16, Murali Krishna wrote:

> How the server is calculating the lease time which is not the one
> defined as per the conf file.

What have you configured on the server for the 'default-lease-time'
parameter?

Niall O'Reilly

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users