Perhaps one of the most overlooked elements of network management is that of time synchronization. If its importance in the overall health of the network were better understood, then perhaps it would be paid more attention. In this article, I’ll discuss time synchronization and the Network Time Protocol.
Why Synchronization Matters
In a local area network (LAN), time synchronization is important because it affects components such as file systems and applications. If the time being issued to the server by the system hardware clock is incorrect, it is quite possible for corruption to occur within applications, particularly in complex systems such as databases. In wide area networks (WANs), time synchronization is even more essential. The distributed nature of WANs greatly increases the probability of an incorrect timestamp, not to mention the fact that WANs often span time zones, further complicating the issue.
One of the best (and most used) examples of the importance of time synchronization is that of e-mail. Imagine receiving an e-mail, the timestamp of which indicates that it was received before it was sent. Very confusing. Another more frightening example includes the computers used by air traffic controllers, but we won’t even go there. So, how does an operating system get the wrong time?
For the most part, operating systems take their time from the local hardware clock of the system on which they are loaded. Although hardware clocks have improved in terms of accuracy and reliability, they are still prone to inaccuracies. In addition, the one-to-one relationship of the operating system and the machine on which it is running means that it is very possible for two different systems on a network to have different times. What is needed is a mechanism that allows systems to synchronize themselves with a reliable time source and subsequently with each other. The mechanism is the Network Time Protocol (NTP).
Guidelines pertaining to the use of Network Time Protocol time sources are available on the Internet. A document describing these Rules of Engagement, along with a list of public time servers, can be found here.
NTP operates over UDP on port 123. If you’re using a firewall, you may need to change the firewall configuration so that NTP traffic can flow through.
Network Time Protocol
NTP is not a new protocol; in fact, it’s been around since the 1980s. The current version of NTP, version 4, is relatively new, and previous versions are still well supported. Great care is taken to ensure that new versions of NTP are backward compatible. The generic nature of NTP means that it is platform independent, and NTP support is available for almost all popular platforms including Linux, Unix, Windows NT/2000, Novell NetWare, Windows 95/98, Mac, as well as other networking devices such as routers. There is even a version for Palm! In many cases, shareware and freeware versions of NTP server and client software are available. Some of these use the lighter Simple NTP (SNTP) protocol, which is based on standard NTP but has less overhead.
Before time can be synchronized by NTP, the correct time must first be ascertained. One of the most popular methods of obtaining this information is from Internet-based public time servers. The servers are structured in a tiered model, with those at the top tier designed to be the most accurate. These top-level Internet time servers are known as Primary, or Stratum-1, time servers. Stratum-1 servers provide accurate time by synchronizing with reliable sources such as the Global Positioning System or purpose-specific radio broadcasts. To ensure that these Primary time servers are not overwhelmed with requests, a number of other servers are also configured as Secondary, or Stratum-2, time servers. Although there may be small differences in time between the Stratum 1 and 2 servers, the possible change is limited and makes no difference to most networks.
The specifics of setting up time synchronization and using NTP on a system will depend on the platform(s) you are using. In most instances, setup is simply a case of installing (and if necessary compiling) the NTP software, loading it, and pointing it at a reliable time source. Depending on how many other devices you want to synchronize, you can then configure NTP on other devices to also point to the reliable time source, or to the original server that is receiving time. In turn, other servers can be configured to receive time from these other servers, creating a stratum model of your own.
The question of which time source to point to is an interesting one. As with many things related to the Internet, time servers are maintained, added to, and amended by people and organizations on a voluntary basis. As such, neither the availability nor the accuracy of the servers and/or service is guaranteed. It would be easy to assume that the Stratum-1 time sources are completely accurate, but it’s not always the case. A survey conducted by individuals at MIT in 1999 found that a large number of the Stratum-1 servers were issuing the wrong timein one case, by over six years!
Setting Up NTP
Setting Up an NTP Time Server
Synchronizing your systems with one of these public time servers may be appropriate if all your systems have access to a public NTP time server, but in practicality it may not be possible. A more reliable, secure, and self-sufficient option is to create a reference time server of your own, and then use it to provide time to servers across your enterprise. To create an NTP time server, you will first need a mechanism for ascertaining accurate time, such as a radio receiver or GPS time receiver. These devices commonly come as either plug-in expansion cards or as external devices that plug into the RS-232 port on the system in question. Prices start at a few hundred dollars and go up from there. Using these devices, the local clock on the system is kept accurate. NTP software can then be used to communicate this time to the operating system and other servers.
Although time serving is designed to be a low-overhead service, if you have many clients who will require synchronization, consider creating a dedicated time server or purchasing a purpose-made time server in a box system. The only drawback is that these can easily cost in excess of $5,000. This strategy may sound expensive, but when you consider the money often invested in other areas of network management and resilience, it is still quite reasonable.
As systems become more and more distributed, the importance of having accurate time across the enterprise will increase accordingly. Network Time Protocol fulfills this need in a relatively simple and easy to implement manner. //
Drew Bird (MCT, MCNI) is a freelance instructor and technical writer. He has been working in the IT industry for 12 years and currently lives in Kelowna, B.C., Canada. You can e-mail Drew at [email protected].