[ntp:questions] Windows NTP setup problem.

Tualha Khan tualhakhan at truition.com
Tue Feb 19 19:52:53 UTC 2008


Hi Everyone,

Thanks for all the inputs. I have gone through the documentation once
more, and did find some interesting pieces, which I was missing earlier.


Long story short (incase you think its just too much garbage), I can't
sync two machines with each other, incase there is no external time
source available. If I change the time of one of the server's by a few
minutes (less than 1024 seconds), then also, they don't re-sync each
other, they just maintain that time gap.

Here is a long email which I had to write to my superior. I know its not
relevant or appropriate to read the long email, but I hope you can make
an exception.

Thanks & Regards,
Tualha

###############################################

I have been trying to set this NTP service on two of our test servers
here. Following is what I have noticed, alongwith some pointers from ntp
mailing list:

1) I referring to two external time servers which are defined as stratum
1.
	tic.nrc.ca prefer
	tock.usask.ca
	
2) Both the servers will resort to their own times as last resort.
	server 127.127.1.0
	fudge 127.127.1.0 stratum 12
	
3) Both the servers are configured to feed off of each other incase the
external time sources are unreachable.
	On first server:
		server 192.168.3.114
	On second server:
		server 192.168.3.210
		
4) The internal servers will authenticate each other through public key
cryptography.\
	crypto pw abc123
	keysdir "D:\Program Files (x86)\NTP\etc\keys"


Now, the problem part. Under my test conditions, i have both servers
configured as follows:

	#crypto pw abc123
	#keysdir "D:\Program Files (x86)\NTP\etc\keys"

	server 127.127.1.0
	server tic.nrc.ca prefer
	server 192.168.3.114 OR server 192.168.3.210
	fudge 127.127.1.0 stratum 12
	#server tock.usask.ca
	#peer 192.168.3.114 autokey
	
	(some parts commented due to testing.)
	
If these servers are unable to reach the external time source, they will
not try to sync up each other. While the services are running, if I
manipulate any of the server's clock, the other one will notice the time
offset, but will not do anything to sync itself to that clock or help
other clock sync to itself. Its as if, they will continue to run with
the time gap. 

However, if I restart the server (not the service), the time gets
sync'ed at the startup. I was assuming that the restart of the ntp
daemon will take care of it, but that does not happen. 
Also, what I have read in the documentation is, that, any time
difference greater than 1024 (~17 minutes) between the two servers, will
terminate the ntp daemon. In that case, the option is to set the clock
close to the minute and restart ntpd to take over.

I have tried the configuration by setting the internal servers as both,
"peer" or "server", where they are heirarchically defined as:

	As server it makes its own time available as reference time for
other clients. 
	As peer it compares its system time to other peers until all the
peers finally agree about the "true" time to synchchronize to. 


Another thing to note, as per the documentation:

"Each NTP daemon can be configured to use several independend reference
time sources. It synchronizes to the reference time source with best
stratum and lowest jitter and delay. If that reference time source
becomes unavailable then the daemon automatically switches to the best
of the remaining time sources which may also result in a change of the
daemon's stratum value."

So, for example, in our case, the server which has the "wrong" time
(192.168.3.114), the ntpq -p output is as follows:

	Checking current status of NTP service with ntpq -p
	     remote           refid      st t when poll reach   delay
offset  jitter
	
========================================================================
======
	*LOCAL(0)        .LOCL.          12 l   47   64  377    0.000
0.000   0.001
	 tic.nrc.ca      .INIT.          16 u    -   64    0    0.000
0.000   0.000
	 CATEST02        LOCAL(0)        13 u   42   64  377    0.259
534511.   7.910

Which may mean, that it will not sync its time with CATEST02
(192.168.3.210), since that server has more jitters and lower stratum
(13) than its local clock (12).

On absolutely different note, I have also read that, incase we go with
ntpd, then the client machines on the network will not do time
synchronization with the domain controllers automatically. We will have
to configure each of them individually to get their time from the domain
controller machine.

And lastly, I have not been able to see any authentication flags for the
w32time windows time service. The tool is called w32tm.

########################################################################
####
 
 
This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. 
 
Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.



More information about the questions mailing list