Troubleshoot Network Time Protocol (NTP)

Introduction

This document provides information on how to troubleshoot common problems with Network Time Protocol (NTP).

Prerequisites

Requirements

Cisco recommends that you have a good understanding of how NTP works and a good knowledge of Network Time Protocol.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

Network Time Protocol (NTP) is widely used in order to synchronize a computer to Internet time servers or other sources, such as a radio or satellite receivers or telephone modem services. It provides accuracies typically less than a millisecond on LANs and up to a few milliseconds on WANs. Typical NTP configurations utilize multiple redundant servers and diverse network paths in order to achieve high accuracy and reliability.

NTP uses Marzullo’s algorithm in order to synchronize the time with the current version of NTP. It can maintain time over the public Internet to within 10 milliseconds and can perform even better over LANs. NTP time servers work within the TCP/IP suite and rely on User Datagram Protocol (UDP) port 123.

NTP servers are normally dedicated NTP devices that use a single time reference to which they can synchronize a network. This time reference is most often a Coordinated Universal Time (UTC) source. UTC is a global time scale distributed by atomic clocks over the Internet, over specialist long wave radio transmissions, or with the Global Positioning System (GPS) network. Dedicated NTP servers are required for Security, Protection, Accuracy, Legality, and Control.

The NTP algorithm uses this time reference in order to determine the amount to advance or retreat the system or network clock. NTP analyzes the timestamp values and the frequency of errors and its stability. An NTP server maintains an estimate of the quality of both the reference clocks and itself.

Troubleshoot Information

This section lists some common issues that can be encountered with NTP and provides solutions for each.

Unable to Sync NTP to W32 Based Time Service

When Cisco routers are configured to use the NTP servers placed in the Active Directory, the Cisco routers do not receive any NTP packets from the NTP server. This issue occurs because Cisco routers use NTP and Active Directory domains use W32Time service. W32Time uses Simple Network Time Protocol (SNTP), a subset of NTP, for time synchronization. SNTP and NTP use the same network-packet format. The main difference between SNTP and NTP is that SNTP does not provide the error-check and filtering functions that NTP provides. Cisco router and switches use NTP and allow for all error-checking and filtering functions provided by NTP v3.

Windows W32Time shows that it is an SNTP implementation inside (rather claiming itself NTP). Cisco IOS-NTP, which tries to sync with W32Time, gets its own root-dispersion value that it sends to the W32Time and this proves costly for Cisco IOS-NTP to synchronize. Because the root-dispersion value of Cisco IOS-NTP goes higher than 1000 ms, it unsynchronizes itself (clock-select procedure). Since the Cisco IOS based routers run the full RFC implementation of NTP they do not sync to an SNTP server. In this case the output of the show ntp associations detail command shows that the server is flagged as insane, invalid. The root dispersion value is in excess of 1000 ms, which causes the Cisco IOS NTP implementation to reject the association. Routers that run Cisco IOS can be unable to synchronize to an NTP server if it is a Windows system that runs the W32Time service. If the server is not synchronized, the routers are not able to transmit to and receive packets from the server.

In order to workaround this issue and sync a Cisco IOS based router, use an authoritative NTP server on the Internet, a UNIX box that runs NTPD or a GPS on certain platforms. As an alternative, you can choose not to run the W32Time service on the Windows system. Instead, you can use NTP 4.x. All versions of Windows 2000 and later can serve as an NTP server. Other machines on the network can then use the NTP server to synchronize their time.

Routers Cannot Sync with Public Time Servers

These are the possible reasons that routers are not able to sync with the public time servers:

• Access control lists that do not permit UDP port 123 packets to come through

• Misconfiguration in the routers, such as the clock timezone and clock summer-time commands are absent on the routers

• Public time server is down

• NTP server software on NT or UNIX is misconfigured

• More traffic is on the router and more traffic on the way to the server

• NTP master lost sync and router loses sync periodically

• High CPU utilization

• High offset and more between the server and the router (use the show ntp association detail command to check for this)

Error: Strata too high - too many indirections from sensor to master NTP server

This error message appears when the sensor attempts to sync to a server that reports its stratum as 15. This is because a server stratum value of 15 makes the sensor stratum value 16, which is illegal. As a result, the sensor instead rejects the server and displays the Strata too high - too many indirections from sensor to master NTP server error message.

NTP uses the concept of a stratum to describe how many NTP hops away a machine is from an authoritative time source. That error message indicates that the NTP stratum reported by the NTP server is too high. The stratum is a number between one and 15 that indicates how far removed the server is from a precision reference clock. Generally systems that are directly synchronized to an atomic clock report their stratum as one. A host that is synced to a stratum one NTP server but also serves as an NTP server for other hosts reports its stratum as two to those hosts, with each successive layer of servers having a stratum that is one higher than its parent.

If you use a Linux host as an NTP server, hard-code the stratum that it reports rather than let it calculate the stratum automatically. If it is a Linux or UNIX box, the NTP server is configured by the file /etc/ntp.conf, and the fudge command is used in order to hard-code the stratum. The server always reports a stratum value one higher than the fudge value to its clients.

Related Information

• Network Time Protocol: Best Practices White Paper
• The Network Time Protocol (NTP) Distribution
• NTP Debugging Techniques
• Technical Support & Documentation - Cisco Systems