Regarding the dhcp lease time

[Rob Janssen]

Simon Hobson wrote:
> 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 ?
>

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