01-28-2023 06:03 PM
Helllo,
We do experience the following issue:
Clock between Client and Server is off by 16 minutes, though NTP is synchronized.
Issue:
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 172.16.1.253
ntp server 172.16.1.251
Standard IP access list 20
10 permit 172.16.1.253 (31374 matches)
20 permit 172.16.1.251 (31302 matches)
30 deny any (17120 matches)
client#sh ntp associations
address ref clock st when poll reach delay offset disp
*~172.16.1.251 10.1.1.33 3 246 1024 377 15.625 1.986 30.400
+~172.16.1.253 10.1.2.33 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 72.16.1.251
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.
01-28-2023 06:26 PM - edited 01-29-2023 02:24 AM
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.
01-28-2023 07:07 PM - edited 01-28-2023 07:11 PM
Hello,
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:
https://www.cisco.com/c/en/us/support/docs/ip/network-time-protocol-ntp/116161-trouble-ntp-00.html
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
-David
01-29-2023 01:37 AM
just wait it, check again after half day you will see the offset will be less than 16 min.
01-29-2023 05:33 PM
Hi,
What are you using as the NTP server? What is the output of "show ntp associations detail" on the client and server.
Thanks
01-29-2023 10:39 PM
Hello
Try syncing the Software./Hardware clocks of the switch/router
ntp update calendar
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide