Re: NTP issue on CUCM 12.0.1 - Page 2

rwesel · ‎04-27-2021

Hello,

I have an issue on our CUCM for which I cannot find a solution.

NTP on CUCM publisher show still unsynchronised.

NTP servers are Solaris and seems to be NTPv4.
NTP servers are reachable.
Other devices (Switches, Linux, ...) can synchronise with these NTP servers.
Hints from Cisco document "NTP Troubleshooting on Cisco Unified Communications Manager" didn't help.
We have one subscriber that is synced with the publisher.

Does anyone have any idea how I can solve the problem?

Thank you

admin:utils ntp status 
ntpd (pid 9284) is running...

remote        refid  st t when poll reach delay   offset    jitter
==============================================================================
192.168.1.21  .DCFa. 1  u 38   64   3     1.791   -19576.   17723.3
192.168.1.22  .PPS.  1  u 37   64   3     2.984   -19864.   17713.5

unsynchronised
polling server every 8 s

Current time in UTC is : Tue Apr 27 07:34:27 UTC 2021
Current time in Europe/Berlin is : Tue Apr 27 09:34:27 CEST 2021

admin:utils network capture port 123
Executing command with options:
size=128 count=1000 interface=eth0
src=dest= port=123 
ip= 
10:00:02.525354 IP cucm01.54177 > 192.168.1.21.ntp: NTPv4, Client, length 48
10:00:02.526615 IP 192.168.1.21.ntp > cucm01.54177: NTPv4, Server, length 48


10:00:07.597767 IP cucm01.ntp > 192.168.1.22.ntp: NTPv4, Client, length 48
10:00:07.601732 IP 192.168.1.22.ntp > cucm01.ntp: NTPv4, Server, length 48

admin:file view activelog syslog/messages.1
...
Apr 25 03:29:05 cucm01 user 2 platform: The local NTP client is off by more than the acceptable threshold of 3 seconds from its remote NTP system peer. The normal remedy is for NTP Watch Dog to automatically restart NTP. However, an unusual number of automatic NTP restarts have already occurred on this node. No additional automatic NTP restarts will be done until NTP time synchronization stabilizes. This is likely due to an excessive number of VMware Virtual Machine migrations or Storage VMotions. Please consult your VMware Infrastructure Support Team.
Apr 25 03:30:05 cucm01 user 4 platform: The local NTP client is off by more than the acceptable threshold of 3 seconds from NTP server 192.168.1.21. Restarting NTP ...
Apr 25 03:30:05 cucm01 user 6 ilog_impl: Restarting NTP as time offset is -145.010660 msec.
Apr 25 03:30:06 cucm01 daemon 4 init: ntpd pre-stop process (3978) terminated with status 2
Apr 25 03:30:06 cucm01 daemon 4 init: ntpd main process (29599) killed by TERM signal
Apr 25 03:30:06 cucm01 user 6 ilog_impl: NTP servers list: 192.168.1.21 192.168.1.22
Apr 25 03:30:06 cucm01 user 6 ilog_impl: ntpdate query response: server 192.168.1.21, stratum 1, offset -145.560090, delay 0.02640#01225 Apr 03:30:06 ntpdate[4196]: step time server 192.168.1.21 offset -145.560090 sec (rc=0).
Apr 25 03:30:06 cucm01 user 6 ilog_impl: ntpdate query response: server 192.168.1.22, stratum 1, offset -145.666639, delay 0.02815#01225 Apr 03:30:06 ntpdate[4212]: step time server 192.168.1.22 offset -145.666639 sec (rc=0).
Apr 25 03:30:07 cucm01 user 6 ilog_impl: NTP server '192.168.1.21' has minimum stratum (1) and delay (0.02640).
Apr 25 03:27:41 cucm01 user 6 ilog_impl: ntpdate 192.168.1.21 response: 25 Apr 03:27:41 ntpdate[4231]: step time server 192.168.1.21 offset -145.718609 sec
Apr 25 03:27:41 cucm01 user 4 platform: A large time correction of 145.718609 seconds by NTP server 192.168.1.21 has occurred. NTP Watch Dog will automatically restart NTP if required. No manual action is required.
Apr 25 03:27:41 cucm01 user 6 ilog_impl: ntpdate 192.168.1.21 response: 25 Apr 03:27:41 ntpdate[4252]: adjust time server 192.168.1.21 offset -0.080398 sec
Apr 25 03:27:41 cucm01 user 6 ilog_impl: ntpdate 192.168.1.21 response: 25 Apr 03:27:41 ntpdate[4271]: adjust time server 192.168.1.21 offset -0.142787 sec
Apr 25 03:27:41 cucm01 user 6 ilog_impl: NTP time snchronization successful.
Apr 25 03:27:42 cucm01 daemon 5 ntpd: ntpd 4.2.6p5@1.2349-o Mon Feb 6 07:22:46 UTC 2017 (1)
Apr 25 03:27:42 cucm01 daemon 5 ntpd: proto: precision = 1.117 usec
...

admin:show version active 
Active Master Version: 12.0.1.10000-10
Active Version Installed Software Options: 
cmterm-ata191.12-0-1-0301-002.k3.cop
cm-locale-de_DE-12.0.1.2000-1.cop

mn4 · ‎10-27-2021

Hello rwesel,

we are having the same problem.

Was this ever fixed?

If yes can you share the details?

Thank you

MN

mHadi · ‎10-30-2021

hi dear friends,

i have this ntp issue with some of my customers..

whats i realized is >> ntp sync with windows-ntp-servers has some issue in overall

best practice for cucm is to synch it with >> Linux-Based-NTP-Servers like >> IOS-Cisco-Devices, or Linux-NTP-SRVs, or Mikrotik-Devices..

Mohammadreza Hadi

rwesel · ‎11-01-2021

My NTP problem has now been solved.

We switched to a mix of NTP Server appliances (Meinberg) and Linux servers.
Somewhere I read that 2 servers are not a good idea, because clients cannot select the correct time source. So we configured 3 NTP servers.
Another problem was with the CUCM subscriber sync state. It should sync with the publisher. At the end it was solved by (subsequent) reboot of the subscriber.

Thank you all for your help.

Stefan

mn4 · ‎11-08-2021

Thank you Mohammadreza and Stefan,

the customer does not accept to use NTP servers other than Windows-based.

I read on the following post that upgrading the VM Hardware to version 19 was beneficial in several cases:

https://community.cisco.com/t5/ip-telephony-and-phones/cucm-12-5-ntp-unsynchronized/td-p/4313179/page/2

As I don't see other options viable with this customer I will try that.

Thank you

MN

mn4 · ‎01-27-2022

Update on this post:

The fix based on VM Hardware upgrade to version 19 appearently had some positive effect as after that CUCM nodes got back synchronized.

However after a few days I noticed that the CUCM was unsynchronized again and it would flap sync/unsync.

Cisco TAC confirmed that Windows NTP is not the best option for the CUCM and highlighted that our customer Windows NTP server is version 3, while CUCM works on NTP v4.

Above conditions are not guaranteed by Cisco (it may work or it may not).

We ended having the customer using public NTP servers.

Thanks.

MN

Roger Kallberg · ‎01-27-2022

It has been known a long time that Windows time servers does not work well with Cisco equipment, and likely others as well. This is because the NTP implementation made by Microsoft does not follow the defined standards set by the standardization body. Not a to surprising thing as it is known to have happened that MS doesn't think that they need to follow standards. ':-|'