How to Configure NTP — Part 3
The right NTP resource can make the difference between success and failure.
In my first blog in this series about Network Time Protocol (NTP), I defined the relevant terms of this often-overlooked networking function. My second blog walked through the various NTP configurations options. This final blog will help you get started on the right foot by sharing both good and bad sources for NTP servers so you know exactly where to go for reliable time resources.
Unreliable NTP Sources
The selection of NTP sources is equally as important as the number of NTP sources configured. There are some different sources out there, so I’ll start with sources to avoid before getting into the most reliable sources.
NTP Pool by FQDN
NTP Pool addresses configured by FQDN, such as 0.us.pool.ntp.org, are best avoided for a couple of reasons: First, any NTP server can join the pool, therefore, selection of the NTP server is completely random. And second, accuracy and longevity of the NTP servers in the pool is unknown as well.
Google Time Servers
Google Time servers should be avoided unless all devices within the enterprise are referencing Google time sources. This is because of Google’s use of a proprietary technique called time smearing to avoid leap seconds. This may have negative knock-on effects on Cisco UC applications unless it is used consistently.
Microsoft Domain Controllers
Prior to 2012 R2, Windows servers by default served up an incompatible version of NTP with numerous Cisco UC applications. This compatibility limitation has become less of an issue, but using Microsoft Domain Controllers as your internal NTP servers still should be avoided for a couple of reasons. First, unrelated server changes have been known to cause NTP outages. And second, decommissioning/replacement/migration of domain controllers is a relatively common occurrence that can cause NTP outages and possible licensing impacts for some Cisco UC applications.
Virtual Machines
Virtual machines should not be used for NTP servers. The issue involves the inconsistency of the time drift within a virtual environment. For example, if a physical machine drifts 12 seconds every 30 days, NTP compensates for this and does so very well. A virtual machine, on the other hand, can drift anywhere from 4 to 70 seconds every 30 days. NTP is not designed or capable of tracking that level of change, and, therefore, would cause out-of-sync events more frequently than physical NTP servers.
Recommended NTP Sources
Having reliable and accurate NTP sources is critical, but how do know which ones to select with so many options available? It is recommended you select reliable, stable and permanent NTP sources from the list of Stratum 1 and Stratum 2 OpenAccess NTP servers on the NTP Project’s website.
Good choices for permanent NTP sources are universities, government agencies and municipalities. Businesses, unless they are large enterprises, should be avoided because of the potential for closings and acquisitions of such entities. Here is a brief list of Stratum 1 and Stratum 2 sources.
To wrap up, following these best practices in setting up the timing of your network will go a long way toward helping troubleshoot and pinpoint issues, as well as proactively avoiding future problems.