Linux ( RHEL6.4) NTP issues

[Raja_b02]

Hi All,

We are trying to point our Linux VMS runningNTP version 4.2.6p5 to Windows 2008 R2 ( NTP service).

ntpdate -u < domain controler> works fine

UPD port 123 is open . I have checked using NMAP utility

$ ntpstat -p

unsnchronized

timeserver restarting

polling every 64s

No major changes done to the standard /etc/ntp.conf file except pointing to the windows DC for NTP service.

ntpq>as

SHOWS reject for NTP servers , but they are reachable.

Please help !!

Regards,

Raja

P.S. This thread has been moved from Linux > System Administration to Linux > networking. - Hp Forum Moderator

[Matti_Kurkela]

What is the output of "ntpq -np"? How large are the delay/offset/jitter values?

NTP protocol always distributes UTC time, but Windows system clock runs in local time.

So if you are using a Windows-based NTP service, it is very important that the timezone setting is set correctly on the Windows server: otherwise the conversion from the local time in Windows system clock to UTC time for NTP will produce an incorrect result.

Unix and Linux systems run their system clocks fundamentally in UTC time, so it is likely that your Linux VMs already have the correct timezone setting. But you should still check the timezone settings to be sure. In any Unix/Linux system, "date -u" should always return a correct UTC timestamp.

When a VM starts up, it may inherit its system clock time from the host platform - and if the host platform's clock or timezone setting is wrong, the system clock may have a value that is too different from real time, causing ntpd to reject a NTP time server or to abort completely.

On virtual machines, VMware recommends adding this setting in the beginning of /etc/ntp.conf:

tinker panic 0

Ref:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427

This is because the virtualization host platform may "steal" some processing time from the VM if the VM is idle, causing the VM's system clock to sometimes seem slow compared to real time.

Other virtualization platforms may have similar recommendations: check the documentation of your virtualization platform.

[Raja_b02]

Hi MK,

Appreciate your response. Here are some more details. FYI, I am testing this on a Physical server. Tryig to point to AD server running Windows 2008 R2.

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.137.28.11    .LOCL.           1 u   28   64  377    0.905  -73.356  88.051
 10.137.28.12    10.137.28.11     2 u   28   64  377    0.943  -84.742  87.031

# ntpstat -p
unsynchronised
  time server re-starting
   polling server every 8 s
[root@deherwspldb01 etc]# ntpq
ntpq> as

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 65492  9024   yes   yes  none    reject   reachable  2
  2 65493  9024   yes   yes  none    reject   reachable  2
ntpq> exit

[root@deherwspldb01 etc]# date
Wed Dec 18 09:02:42 CET 2013

[root@deherwspldb01 etc]# clock
Wed 18 Dec 2013 09:02:44 AM CET  -0.239436 seconds

[root@deherwspldb01 etc]# /sbin/hwclock
Wed 18 Dec 2013 09:02:49 AM CET  -0.969215 seconds

[root@deherwspldb01 etc]# date -u
Wed Dec 18 08:02:51 UTC 2013

Regards,

Raja

[Raja_b02]

Further more, please find the below o/p from one of the Linux servers pointed to Widnwos DC

 ntpdc -c sysinfo
system peer:          0.0.0.0
system peer mode:     unspec
leap indicator:       11
stratum:              16
precision:            -24
root distance:        0.00000 s
root dispersion:      0.04388 s
reference ID:         [73.78.73.84]
reference time:       00000000.00000000  Mon, Jan  1 1900  1:00:00.000
system flags:         auth monitor ntp kernel stats
jitter:               0.000000 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s

Timezone on Windows AD is set to

(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna  

On LInux

# ls -l /etc/localtime
lrwxrwxrwx. 1 root root 33 Dec 18 08:37 localtime -> /usr/share/zoneinfo/Europe/Berlin

[Matti_Kurkela]

(Sorry about the late answer.)

Is the Windows DC synchronized to some real NTP server, or is it just using its own system clock as a time source?

On the Windows DC, what is the value of the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags registry key?

If the Windows DC is synchronized to a real upstream NTP server, the value of the AnnounceFlags registry key should be set to 5 (DWORD value). If the Windows DC is supposed to use its internal clock, the value of the AnnounceFlags registry key should be 0xA (i.e. 10 represented in Hexadecimal).

See also:

http://support.microsoft.com/kb/816042/en-us

If you stop ntpd on the Linux server, and then run "ntpdate -d <Windows.server.IP.address>", what is the output? (Replace the <Windows.server.IP.address> with the actual IP address, of course.)

The "reference time", "originate timestamp" and "transmit timestamp" should all have non-zero values in ntpdate -d output. If the "reference time" has a zero value (i.e. Mon, Jan 1 1900...), then the Windows server is unsure of the correctness of its time, and you should fix the Windows server first.