Regarding the dhcp lease time

[Bruce Hudson]

On Mon, May 13, 2019 at 08:46:46PM +0530, Murali Krishna wrote:
 

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

    I suspect your timeline is incomplete. Let me propose an alternative (for
which, I confess, I have no real evidence):

    1. Client initiates DHCP Request for 3600s(1hr)
    2. Server acknowledges this lease and records it in the lease file,
       ending at an absolute time of "now+1 hour".

    3. System admin sets the clock back 5 years.

    4. Client initiates DHCP Request for 3600s(1hr)
    5. Server acknowledges the existing, still valid lease, ending at an
        absolute time the server sees as 5 years in the future.

    When you change the clock, are you deleting the existing lease database?
--
Bruce A. Hudson | [hidden email]
ITS, Networks and Systems |
Dalhousie University |
Halifax, Nova Scotia, Canada | [phone]
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Murali Krishna]

Hi,

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

parameter?

600s is configured in the conf file.

>>When you change the clock, are you deleting the existing lease database?

Nothing is modified w.r.t the lease database.

Thanks & Regards,

Muralikrishna

On Mon, May 13, 2019 at 10:24 PM Bruce Hudson <[hidden email]> wrote:

On Mon, May 13, 2019 at 08:46:46PM +0530, Murali Krishna wrote:

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

    I suspect your timeline is incomplete. Let me propose an alternative (for
which, I confess, I have no real evidence):

    1. Client initiates DHCP Request for 3600s(1hr)
    2. Server acknowledges this lease and records it in the lease file,
       ending at an absolute time of "now+1 hour".

    3. System admin sets the clock back 5 years.

    4. Client initiates DHCP Request for 3600s(1hr)
    5. Server acknowledges the existing, still valid lease, ending at an
        absolute time the server sees as 5 years in the future.

    When you change the clock, are you deleting the existing lease database?
--
Bruce A. Hudson                         | [hidden email]
ITS, Networks and Systems               |
Dalhousie University                    |
Halifax, Nova Scotia, Canada            | [phone]
_______________________________________________
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]

Murali Krishna <[hidden email]> wrote:

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

OK, basically you are breaking the system and the system responds in a correspondingly broken fashion.
Neither the DHCP protocol nor the server & client are designed to handle "time goes backwards by 5 years" - what happens if you do that is undefined.

If you go to a doctor and say something like "when I do X, it hurts", the doctor is likely to suggest that you don't do X.
In the same manner, my advice would be to stop breaking things by altering the clock. Or if you really must alter the clock, stop the DHCP server beforehand and keep it stopped until you've reset the clock back to the correct time.

And don't expect correct DHCP operations with the server using a self-assigned link-local address.

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

[Murali Krishna]

Hi,

Thanks for the clarification. 

As i mentioned in earlier email(when we have 4.2.1-P1 at both server and client side ), the server is responding correctly(with the configured lease time) when the system time changes. There was no huge lease offered as well in the system.

Thanks & Regards,

Muralikrishna

On Tue, May 14, 2019 at 12:56 AM Simon Hobson <[hidden email]> wrote:

Murali Krishna <[hidden email]> wrote:

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

OK, basically you are breaking the system and the system responds in a correspondingly broken fashion.
Neither the DHCP protocol nor the server & client are designed to handle "time goes backwards by 5 years" - what happens if you do that is undefined.

If you go to a doctor and say something like "when I do X, it hurts", the doctor is likely to suggest that you don't do X.
In the same manner, my advice would be to stop breaking things by altering the clock. Or if you really must alter the clock, stop the DHCP server beforehand and keep it stopped until you've reset the clock back to the correct time.

And don't expect correct DHCP operations with the server using a self-assigned link-local address.

_______________________________________________
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