Cisco NTP Clock is unsynchronized

Question

I have two internap NTP server and i set them up on Cisco Router but this is what i am getting.

R1#show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~10.1.1.50       129.6.15.28      2      4     64   377  0.764 -26.612  1.962
+~10.1.1.51       129.6.15.28      2     10     64   377  0.766 -18.581  1.946
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

Status:

R1#show ntp status
Clock is unsynchronized, stratum 3, reference is 10.1.1.50
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
ntp uptime is 85000 (1/100 of seconds), resolution is 4000
reference time is DB1E7441.2B020CC0 (12:22:25.168 EDT Wed Jun 29 2016)
clock offset is -27.2765 msec, root delay is 78.64 msec
root dispersion is 37.11 msec, peer dispersion is 1.95 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 37 sec ago.

But its showing correct time, Why show ntp status showing unsynchronized ??

R1#show clock
.12:23:41.217 EDT Wed Jun 29 2016

EDIT

!
ntp server vrf Mgmt-intf 10.1.1.50
ntp server vrf Mgmt-intf 10.1.1.51
!
clock timezone EST -5 0
clock summer-time EDT recurring
!

Question:

We have two ntp server NTP1 & NTP2 and NTP server syncing time with public NTP server, should i put two different public NTP server list on NTP1 & NTP2 server or public NTP list supposed to be same on both ntp1 and ntp2 server, what is the best practice for that?

UPDATE:

Output:

R1#show ntp associations detail
10.1.1.50 configured, ipv4, sane, valid, stratum 2
ref ID 199.102.46.79  , time DB1E94EB.26269DEA (14:41:47.149 EDT Wed Jun 29 2016)
our mode client, peer mode server, our poll intvl 512, peer poll intvl 512
root delay 29.98 msec, root disp 33.12, reach 377, sync dist 54.98
delay 0.14 msec, offset 27.2130 msec, dispersion 1.08, jitter 0.97 msec
precision 2**19, version 4
assoc id 37176, assoc name 10.5.3.60
assoc in packets 154, assoc out packets 155, assoc error packets 0
org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
rec time DB1E95F8.319EEF80 (14:46:16.193 EDT Wed Jun 29 2016)
xmt time DB1E95F8.319EEF80 (14:46:16.193 EDT Wed Jun 29 2016)
filtdelay =     0.84    0.84    0.85    0.14    0.15    0.84    0.84    0.79
filtoffset =   27.25   27.41   26.89   27.21   27.35   27.18   27.11   27.16
filterror =     0.97    1.00    1.03    1.06    1.09    1.12    1.15    1.18
minpoll = 6, maxpoll = 10

10.1.1.51 configured, ipv4, our_master, sane, valid, stratum 2
ref ID 199.102.46.79  , time DB1E937E.A19C2C7C (14:35:42.631 EDT Wed Jun 29 2016)
our mode client, peer mode server, our poll intvl 512, peer poll intvl 512
root delay 29.86 msec, root disp 24.49, reach 377, sync dist 47.72
delay 0.16 msec, offset 9.3404 msec, dispersion 1.08, jitter 0.97 msec
precision 2**19, version 4
assoc id 37177, assoc name 10.5.3.61
assoc in packets 154, assoc out packets 154, assoc error packets 0
org time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
rec time DB1E959A.2D3A68F6 (14:44:42.176 EDT Wed Jun 29 2016)
xmt time DB1E959A.2D3A68F6 (14:44:42.176 EDT Wed Jun 29 2016)
filtdelay =     0.83    0.80    0.84    0.16    0.84    0.17    0.83    0.78
filtoffset =    9.09    9.22    9.28    9.34    9.49    9.24    9.60    8.85
filterror =     0.97    1.00    1.03    1.06    1.09    1.12    1.15    1.18
minpoll = 6, maxpoll = 10

Answer 1

According to Cisco, loss of synchronization occurs when the IOS device cannot trust the NTP server. It may be due to packet drops from network congestion.

Cisco has a document specific to NTP troubleshooting:

Network Time Protocol (NTP) Issues Troubleshooting and Debugging Guide

Loss of Synchronization

Loss of synchronization might occur if the dispersion and/or delay value for a server goes very high. High values indicate that the packets are taking too long to get to the client from the server/peer in reference to the root of the clock. So, the local machine cannot trust the accuracy of the time present in the packet, because it does not know how long it took for the packet to get here.

NTP is meticulous about time and will not synchronize with another device it cannot trust or cannot adjust in a way so that it can be trusted.

If there is a saturated link and buffering occurs along the way, the packets get delayed as they come to the NTP client. So, the timestamp contained in a subsequent NTP packet can occasionally vary a lot, and the local client cannot really adjust for that variance.

NTP does not offer a method to turn off the validation of these packets unless you use SNTP (Simple Network Time Protocol). SNTP may not be much of an alternative because it is not widely supported in software.

If you experience loss of synchronization, you should check the links:

• Are they saturated?
• Are there any kinds of drops in your wide-area network (WAN) links
• Is encryption occurring?

Monitor the reach value from the show ntp associations detail command. The highest value is 377. If the value is 0 or low, NTP packets are being received intermittently, and the local client goes out of sync with the server.

debug ntp validity

The debug ntp validity command indicates whether the NTP packet failed sanity or validity checks and reveals the reason for the failure. Compare this output to the sanity tests specified in RFC1305 that are used in order to test the NTP packet received from a server.