NTP Server is not getting time sync from external source.

[Ankitkumar]

Hi all ,

My HP UX server is not able to sync the time from the external source earlier it was working.But now time is not getting sync. I have confirmed with the external service provider as per them service is working fine for other customers.Below is the output from my server.

root@SAMAY:/var/tmp/ntp >ntpq -p

     remote           refid      st t when poll reach   delay   offset    disp

==============================================================================

 14.139.60.107   0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0

 14.139.60.106   0.0.0.0         16 -    -   64    0     0.00    0.000 16000.0

root@SAMAY:/var/tmp/ntp >ntpq -c assoc

ind assID status  conf reach auth condition  last_event cnt

===========================================================

  1 38132  8000   yes    no

  2 38133  8000   yes    no

root@SAMAY:/var/tmp/ntp >ntpdate -d 14.139.60.107

transmit(14.139.60.107)

receive(14.139.60.107)

transmit(14.139.60.107)

receive(14.139.60.107)

transmit(14.139.60.107)

receive(14.139.60.107)

transmit(14.139.60.107)

receive(14.139.60.107)

transmit(14.139.60.107)

server 14.139.60.107, port 123

stratum 1, precision -20, leap 00, trust 000

refid [GPS], delay 0.05623, dispersion 0.00012

transmitted 4, in filter 4

reference time:      d6e0ff7f.e1977fd0  Sat, Mar 29 2014 13:44:55.881

originate timestamp: d6e0ff89.f2327d48  Sat, Mar 29 2014 13:45:05.946

transmit timestamp:  d6e0ff89.eddd8000  Sat, Mar 29 2014 13:45:05.929

filter delay:  0.05682  0.05623  0.05701  0.05663

               0.00000  0.00000  0.00000  0.00000

filter offset: 0.001597 0.001326 0.001719 0.001350

               0.000000 0.000000 0.000000 0.000000

delay 0.05623, dispersion 0.00012

offset 0.001326

29 Mar 13:45:05 ntpdate[13586]: adjust time server 14.139.60.107 offset 0.001326 sec

===============================================================================

I have confirmed with the firewall team also as per them they are able to see the connection request from my server side as it is UDP communication and they are not getting any acknowledgement packets.Nothing is changed, earlier it was working properly.

If some one have any idea about it please revert.

Ankitkumar

[Matti_Kurkela]

root@SAMAY:/var/tmp/ntp >ntpq -c assoc

ind assID status  conf reach auth condition  last_event cnt

===========================================================

  1 38132  8000   yes    no

  2 38133  8000   yes    no

The "status" column shows the Peer Status Words for each remote NTP server.

This is how to interpret it:

http://www.eecis.udel.edu/~mills/ntp/html/decode.html#peer

First, the first two digits are a combination of the Status field and the Select field.

The value is 80, which in the Status field indicates it's a persistent association (i.e. a NTP server or peer configured in ntp.conf) and nothing else.

The second digit includes the Select field, whose value is 0 - meaning "sel_reject", or that the NTP server has been discarded as providing invalid time information.

The third digit is the Count field, which is 0 - no events.

The fourth digit is the Event field. Since the Count field is 0, this is also 0.

The "Flash Status Word" for each remote NTP server might offer more information on why xntpd is dicarding the remote NTP servers. Please run "ntpq -c rv 38132" and "ntpq -c rv 38133" and check the "flash=" field in the output.

The description of the Flash Status Word values is on the same page as the Peer Status Word description, a bit further down.

Your ntpdate output indicates that at least the 14.139.60.107 NTP server is in fact reachable and agrees very closely with your current system time.

Has there been a major system clock adjustment (with either "date" or "ntpdate" command) after the xntpd daemon was started? The change might have confused the xntpd daemon. Try restarting xntpd and see if it syncs with the NTP servers successfully after the restart (might take several minutes).

You should always stop xntpd if you need to make major system clock adjustments with "date" or "ntpdate" commands.

Also, if network interfaces are added, reconfigured or removed, a restart of xntpd might be needed. (A reboot would be best if making major network configuration changes, but I know that may not always be possible with critical production systems...)