Showing results for 
Search instead for 
Did you mean: 

NTP Sync Issue



We do experience the following issue:

Clock between Client and Server is off by 16 minutes, though NTP is synchronized.


ntp client#sh clock
21:05:46.532 est Sat Jan 28 2023


ntp server#sh clock
20:49:33.133 EST Sat Jan 28 2023

Config at NTP client:

1 56 WS-C3850-48P 03.02.03.SE

ntp source Loopback0
ntp access-group peer 20
ntp server
ntp server

Standard IP access list 20
10 permit (31374 matches)
20 permit (31302 matches)
30 deny any (17120 matches)



client#sh ntp associations

address ref clock st when poll reach delay offset disp
*~ 3 246 1024 377 15.625 1.986 30.400
+~ 3 851 1024 377 15.625 2.085 30.401
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

client #sh ntp status
Clock is synchronized, stratum 4, reference is1
nominal freq is 250.0000 Hz, actual freq is 250.0077 Hz, precision is 2**6
reference time is E7804E49.282716F8 (20:45:45.156 est Sat Jan 28 2023)
clock offset is 1.9866 msec, root delay is 18.56 msec
root dispersion is 84.79 msec, peer dispersion is 30.40 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000030746 s/s
system poll interval is 1024, last update was 260 sec ago.


5 Replies 5

Leo Laohoo
Hall of Fame
Hall of Fame

Could be a bug.  IOS-XE version 3.2.3, in my opinion, is not "fit for production".  

Upgrade to 3.6.10 and see if this fixes the issue. 

WARNING:  Do not upgrade to 16.X.X.  Stay with 3.6.10. 



In addition to what @Leo Laohoo said there are some things to note:

1. If the NTP just started syncing it could take a while for it to get closer to matching up, If I remember correctly it only budges a few milliseconds per sync....if that's the case it'll take a while to get close to the actual time.

2. If the time is too far off it may not ever sync properly (probably not in your case as its only 16 minutes) - you can try manually setting the time within a minute of the time manually to see if it syncs up better.

3. Is that the only device in your network that is off? Or is this an entire LAN issue?

4. Looks like your poll interval is 17 minutes (1024 seconds) - maybe change that to 60 seconds or 10 to see if it starts moving the clock as a test.


Some troubleshooting docuemnts:

I'd use the "debug ip packet" with an ACL to make sure that your NTP packets are being processed correctly and you don't see any errors.

Specifically in the document:

This is an example where NTP does not work on received packets. Although NTP packets are received (as shown by debug ip packets), the NTP process does not act on them. For NTP packets that are sent out, a corresponding debug ntp packets output is present, because the NTP process has to generate the packet. The issue is specific to received NTP packets that are not being processed.

So your device could be receiving NTP packets but not processing them correctly. 


Hope that helps


just wait it, check again after half day you will see the offset will be less than 16 min. 



What are you using as the NTP server?  What is the output of "show ntp associations detail" on the client and server.


**Please rate posts you find helpful**

Try syncing the Software./Hardware clocks of the switch/router
ntp update calendar

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: