Many engineers overlook the importance of accurate timekeeping on a router. It is often extremely useful to be able to accurately pinpoint when a particular event occurred. You may want to compare network event messages from various routers on your network for fault isolation, troubleshooting, and security purposes. This is impossible if their clocks are not set to a common source. In fact, the problem is even worse than merely setting the clocks to a single common standard because some clocks run a little bit fast and others run a little bit slow. So they need to be continuously adjusted and synchronized.
Network Time Protocol (NTP) is the de facto standard for Internet time synchronization. The current standard for NTP is Version 3, which is defined in RFC 1305. The IETF is currently developing a new version.
The protocol allows devices to communicate over UDP port 123 to obtain time from an authoritative time source such as a radio clock, atomic clock, or GPS-based time source. An NTP server connected directly to one of these known reliable time sources is called a Stratum 1 timeserver. Stratum 2 timeservers receive their time via NTP from a Stratum 1 server, and so forth, up to a maximum of Stratum 16. Stratum numbers are analogous to hop counts from the authoritative time source. NTP generally prefers lower stratum servers to higher stratum servers unless the lower stratum server's time is significantly different.
The algorithm is able to detect when a time source is likely to be extremely inaccurate, or insane, and to prevent synchronization in these cases, even if the inaccurate clock is at a lower stratum level. And it will never synchronize a device to another server that is not synchronized itself.
The NTP protocol is extremely efficient and lightweight. It can synchronize a client device's clock with the server device's clock to within milliseconds while exchanging packets as rarely as once every 1,024 seconds (roughly 17 minutes). Even over WAN links, NTP is able to synchronize clocks to within tens of milliseconds. To achieve this, it has to have algorithms that estimate and reduce the effects of network jitter and latency. It is also able to use multiple time sources simultaneously for improved reliability and fault tolerance.
As the idea of multiple stratum levels suggests, NTP uses a hierarchical topology. However, this is only relevant to the relationships between NTP clients and servers, which do not need to be physically adjacent on the network. The protocol does not require any particular underlying network topology. Version 3 of the protocol has three different operational modes: master/slave (server/client), symmetric (peers), and a broadcast mode in which the clients passively listen for updates from a server. Some implementations also have a multicast mode that most likely foreshadows some of what will be in Version 4. Cisco has recently added multicast support, which we will discuss in Recipe 14.10.
In the master/slave mode, the client device periodically sends a message to one or more servers to request synchronization. Because the server is a master that is closer to the original time source, its clock is assumed to be more reliable. So the server will synchronize the client's time, but will not allow the client to change its own clock. The server passively listens for these requests.
In the symmetric peer-to-peer mode, both NTP devices synchronize one another. Peers can operate in active or passive mode. However, at least one of a pair of peers must be active, or nobody will ever start the conversation.
The broadcast and multicast modes of operation are used to synchronize a large number of passive client devices in a network. This has the advantage of saving bandwidth caused by multiple requests for synchronization. In most cases, this overhead is minimal, however. These modes have the disadvantage of being less precise than a poll-response model because there is no way for the client device to estimate network latency. The multicast mode is somewhat more useful than the broadcast mode because it allows you to synchronize devices on many network segments from a single source. However, multicast routing must be enabled on the network. We will discuss multicast routing in Chapter 23.
The NTP client and server software runs on most modern operating systems including Unix, Windows, and MacOS. You can find source code and binary executable NTP software for various operating systems at: http://www.eecis.udel.edu/~ntp/software/index.html. The general information web page for all things related to NTP and the ongoing protocol and software development is http://www.ntp.org.
Organizations can purchase their own authoritative time sources or obtain time services via the Internet. There are small, cost-effective Global Positioning Satellite (GPS) Stratum 1 servers on the market today, which you can use as an extremely accurate reference clock. These devices typically cost a few thousand dollars and can be easily rack mounted in a computer room in the core of your network. Alternatively, there are hundreds of public Stratum 1 and 2 timeservers available on the Internet that allow peer devices to connect and synchronize with them free of charge. The extra complication of sending synchronization signals through the public Internet introduces some additional jitter that is somewhat more difficult to estimate. So this method is slightly less accurate than using your own time server, but the difference is rarely more than a few milliseconds, and you can reduce the impact of this problem by synchronizing with multiple servers. For most applications, the publicly available servers are more than adequate.
The web site http://www.eecis.udel.edu/~mills/ntp/servers.htm has useful information about public NTP servers available through the Internet.