[ntp:questions] Synchronizing Linux clients with Windows Server 2003 NTP

David L. Mills mills at udel.edu
Sun Jan 21 03:49:04 UTC 2007


George,

Have you noticed your Windows server is visible to your Linux client, 
but the offset shows -180 ms, which is larger than the step interval? 
Ordinarily, NTP steps the time after 900 s, but you show over this and 
the step has not occured. You need to look at the association billboard 
(rv <assocID>) and see the  flashcodes (flash=xxx). I suspect the 
Windows server packet has the usual casual disregard for the spec and 
says something illegal.

Send the billboard in a message. There might be a simple workaround.

I echo other commentators that, even if a workaround can be found, you 
will get terrible time and in particular are potential victim of 
unstable operation. The NTP clock discipline algorithm expects a stable 
clock source, either SNTP and a radio, or full NTP with clock discipline 
algorithm. It's much safer to use SNTP, rather than NTP, in you clients.

Send the billboard se we can all have a good time bashing Windows.

Dave

george_joby wrote:
> Our requirement is all our linux and nonstop systems synchronise to the
> Windows 2003 server. We do not want Windows to syncronise with an
> external clock and it should just synchronise with its internal clock.
> 
> So what I am doing is just configuring with a client (Redhat Linux) and
> server (windows 2003) to check whether Linux gets synchronise with
> Windows server and that is not happening. Our customer need this setup.
> 
> If i see the ntpq -pn in Linux it will show the correct offset and also
> ntpdate works fine. But Linux not ready to synchronise with Server.
> 
> [root at txnaslload03 ~]# ntpq -pn
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
>  16.74.32.162    .LOCL.           1 u  967 1024  377    0.355  -180.34
>  5.407
> 
> Thanks
> George
> 
> Ry wrote:
> 
>>Richard B. Gilbert wrote:
>>
>>
>>>Isn't port 123 UDP inbound required as well?
>>
>>Not on a stateful firewall, which are the most common type these days.
>>In most firewall configuration tools, "allow UDP port 123 outbound"
>>means that when a outbound packet is sent, the firewall will remember
>>seeing it (that's the *stateful* part) allow a return UDP packet(s)
>>from the destination IP and source port for a few seconds before
>>closing things off again.
>>
>>This assumes all he is doing is configuring his NTP to act as a client
>>to an internet-based NTP server. If he is going to be using
>>symmetric/active or another mode, that's going to require allowing UDP
>>port 123 inbound. But it doesn't seem to me that he would need to do
>>anything like that.
> 
> 




More information about the questions mailing list