"Connection rejected, time mismatch too great" ??

Simon Hobson dhcp1 at thehobsons.co.uk
Wed Apr 4 10:10:18 UTC 2007


Abu Abdulla alhanbali wrote:

>I got this in my failover setup:
>Failover CONNECT to dhcp-failover rejected: Connection rejected, time
>mismatch too great.
>
>I tried to sync the clock by running the xntp process in both machines
>without success. Any Idea of how to solve this.

In what way didn't ntp work ? Your problem description stops at "it 
didn't work" which is not helpful for diagnosis !

How are you trying to set it up ?
Do you get any response from your reference server ?
Are there any firewalls blocking your NTP packets ?

I normally set up one or two machines in an organisation to sync from 
an external source - most ISPs provide a stratum 2 or 3 server for 
their customers. I then configure the rest of the machines in that 
organisation to use those two servers as their master.

At my current job, I have two servers synced to different stratum 2 
public servers, thus giving me redundancy - ie two internal stratum 3 
servers. Each is also configured to use the other should it lose it's 
own reference - but doing so would lower it to stratum 4 and make it 
less attractive to clients. Everything else (both internally and also 
some of our customers) is configured to use both these two servers 
for it's references.

They have been running for months and the time offset between them is 
in the order of a millisecond !


For a smaller organisation, I would suggest syncing one server to a 
public source (such as provided by your ISP), and using that 
internally for all your other servers.


If you cannot find a public server (or even if you can), then I 
suggest you take a look at http://www.pool.ntp.org/



What you should not do is have lots of internal machines all using a 
public server - that is greedy and adds unnecessary load on the 
public servers.


>in addition, What is the distance between the two servers. We have a setup
>in which the primary server in one city and the secondary in another city?

Geographical distance is irrelevant, the only consideration is 
whether IP packets can be transferred in a timely manner. In 
practice, I'd be surprised if any reasonable network gave problems 
due to this.



More information about the dhcp-users mailing list