/mcpThe NTP daemon regularly corrects time, but on a millisecond time scale. A restart of NTP involves that you run an NTP one-shot in order to perform a gross time correction and follow with a restart of the NTP daemon for continued regular micro-corrections. NTP Watchdog polls NTP once a minute on VMware and once every 30 minutes on physical machines. The polling interval is shorter for VMware because the clock in Virtual Machines (VMs) is less stable than on physical machines, and VMware features such as VMotion and Storage Migration adversely affect time. A primary node that runs on VMware must always be configured in order to synchronize with external NTP servers that run on a physical machine(s) to compensate for the higher degree of time drift or delay in a VM. Secondary nodes are always automatically configured to reference the primary node NTP server in order to ensure that all nodes within the cluster are close in time. NTP Watchdog keeps track of the rate at which it restarts the NTP daemon for gross time corrections due to VMWare VMotions and Storage Migrations. If this rate exceeds 10 restarts per hour, NTP Watchdog postpones further restarts until the required rate of restarts falls under 10 per hour. The combined rate of VMotions and Storage Migrations cannot exceed 10 per hour, because this rate is considered excessive. Because of this NTP Watchdog implementation, you do not follow the poll interval, which is seen in utils ntp status. A sniffer capture has revealed 8 NTP polls (sample) every 60 seconds. This is primarily because the NTP implementation uses NTP Watchdog, and how ntpdate polls the NTP server in UC Implementation. Identify NTP Version Used Note: CUCM Publisher is configured with an External NTP server, and the subscriber added to the cluster synchronizes to the Publisher. Note: CUCM Version 9.x and later requires that the NTPv4 server be configured as the preferred NTP server. Run a sniffer capture in order to identify the NTP version used by the configured NTP server: <#root> admin: utils network capture port 123 Executing command with options: size=128 count=1000 interface=eth0 src=dest= port=123 ip= 16:03:03.689725 IP cucmlab.cisco.local.34063 > linux.local.ntp: NTPv4,Client, length 48 16:03:03.690174 IP linux.local.ntp > cucmlab.cisco.local.34063: NTPv3,Server, length 48 CUCM sends an NTPv4 packet and in response, you receive an NTPv3 packet. Although NTPv4 is backward-compatible to NTPv3, CUCM implementation of NTP varies, which results in unsynchronized NTP: