Keeping Time With Your Network

One way to synchronize is to set each network device and PC clock manually. That's like a Navy quartermaster keeping accurate time at sea by synchronizing his watch with a reference clock or chronometer on the ship, and then setting each clock onboard to his watch. This method requires military-like discipline and more resources than most IT departments have. A clock's time can drift several seconds each day if it's left unattended. Time discrepancies among clocks can go from minutes to hours quickly and cause problems with automated actions, data logging and synchronization.

An easier way to keep time is to automate time synchronization in your servers and workstations. Two of the most common approaches use NTP (Network Time Protocol, RFC 1305) 3 and SNTP (Simple Network Time Protocol, RFC 2030) 4. NTP and SNTP synchronize time across geographically dispersed networks over UDP (User Datagram Protocol) Port 123. NTP supports multiple, redundant time sources for always-on, accurate time synchronization, and it can synchronize time to the millisecond.

How It Works

NTP servers operate in a hierarchal network; each level of the hierarchy is called a stratum. Stratum 0, the first level, represents the reference clock. The reference clock can be a GPS (Global Positioning System) signal or the National Institute for Standards and Technology's Automated Computer Time Service (ACTS)--both time-dissemination services. No NTP servers operate at Stratum 0.Stratum 1 NTP servers get their time data from the reference clock. Stratum 2 NTP servers synchronize with Stratum 1 servers. You can have up to 15 levels. For a list of public Stratum 1 and 2 servers see www.eecis.udel.edu/~mills/ntp/servers.html. Be sure to read and honor the access policy of the public NTP servers you use.

NTP servers and NTP clients get time data from Stratum 1 servers, though in practice, NTP clients shouldn't do so because thousands of individual client requests would place too much of a burden on a Stratum 1 server. It's best to set up a local NTP server that your clients use for time services.

The NTP hierarchy is fault-tolerant and redundant. In the diagram below, two Stratum 2 NTP servers are synchronizing to six different Stratum 1 servers, each going over independent paths. The internal hosts are synchronizing with the internal NTP servers. The two Stratum 2 NTP servers coordinate time between themselves. If a path to a Stratum 1 server fails or a Stratum 2 server fails, the redundant Stratum 2 server continues the synchronization process.

Likewise, Stratum 3 hosts and devices can use either of the Stratum 2 NTP servers. More important, using a redundant network of NTP servers ensures that time servers are always available. By synchronizing with multiple time servers, NTP uses the data from all the sources to calculate the most accurate time.

NTP doesn't actually set time. It adjusts the local clock using a time offset, which is the difference between the NTP server's time and the local clock. NTP servers and clients update their times by adjusting the local clock to the current time gradually or all at once.You can configure the NTP client and server parameters to "step" the local clock to the current time if an offset gets too high. But if the offset is less than the maximum offset value of 128 ms, for example, the clock will be changed to the current time gradually. (The gradual change keeps the time continuous). If the clock offset is exceptionally large, however--greater than 1,000 seconds--the NTP server or client will stop adjusting time and wait for human intervention.

Meanwhile, the risk of using any Internet-based service, of course, is that it can become unavailable. So if your organization requires an accurate reference clock to create receipts for real-time transactions or for PKI (public key infrastructure) for authentication/validation, you should set up an internal Stratum 1 time server for more accurate time. These commercial time server platforms, from vendors such as Symmetricom and EndRun Technologies, provide the accurate time via GPS, radio or dial-up modem for internal timekeeping.

Like a network of public NTP servers, an internal time-server platform should be synchronized to multiple reference clocks. And you should deploy multiple Stratum 2 NTP servers that offer multiple paths to the Stratum 1 server.

Timing It Right

So how do you go NTP? First, set up the NTP daemon (see "Step by Step," below), which is available at www.ntp.org. When an NTP client or server first initiates synchronization, it needs to establish which time servers it will use, and that's defined in the ntp.conf file. Next, the NTP daemon needs to determine the properties of the local clock. Within about 15 minutes, the NTP client is synchronized with the NTP server.

The alternative to NTP is SNTP, which comes packaged with Windows 2000. At the protocol level, SNTP is just like NTP, and NTP servers can answer SNTP or NTP queries. But SNTP's timing algorithms for determining time offsets and resolution and redundancy features are different from NTP.

The SNTP client takes the time stamp at face value and sets the clock accordingly, without the in-depth validation process that NTP uses. SNTP should not be used with multiple NTP and SNTP servers because it doesn't have the algorithms to determine the best time source. And in contrast to NTP, SNTP synchronizes down to the nearest second rather than the nearest millisecond.Windows 2000 machines in a domain use SNTP and W32time to automatically synchronize with the Windows Primary Domain Controller (PDC) in a process transparent to the user. But Windows 2000 uses a time source derived from SNTP to synchronize other hosts, so it's a good idea to have an NTP client in the PDC to synchronize to an external source.

Mike Fratto is a senior technology editor based in Network Computing's Syracuse University Real-World Labs®; he covers all security-related topics. Prior to joining this magazine, Mike worked as an independent consultant in central New York. Write to him at [email protected].

Post a comment or question on this story.

There are many ways clients can receive time-server information. It depends on your local architecture and requirements. NTP server authentication is a key part of this process because time data should come from a reliable, trusted source. The exception is a client-server model where the server is unknown to the client from the start of the conversation.

Here are the main NTP architecture models:

• Client-server: This is the typical mode used for NTP deployments, and the one described in this workshop. The client or server is configured to communicate with a specific set of NTP time servers.• Broadcast: The NTP server broadcasts its presence to local networks, and the clients respond through a packet exchange to determine round-trip time and delay. Broadcast mode can be used to synchronize large numbers of hosts on an IP address block.

• Manycast: The clients send an NTP broadcast to a destination network. Once an NTP server responds to the client broadcast, the client will continue to use that specific NTP server. This is useful when hosts are mobile and don't know the address of the current NTP server. Manycast is only available in NTP 4, which is not yet a formal IETF RFC.

• Multicast: NTP clients and servers are configured to use the multicast group address (224.0.1.1) for sending and receiving NTP messages. Make sure your intervening routers support multicast as well. This model is for environments with mobile devices and destination networks that support multicast.1. Download the production Unix tarball and patches. Those are available from www.ntp.org/downloads.html.

2. Unzip and untar the archive. Follow the directions in the readme file to compile and install the programs.

3. Get a list of public time servers on the Internet (www.eecis.udel.edu/~mills/ntp/servers.html). Follow the access policies of the public servers located here.4. Use traceroute (tracert on Windows) to locate time servers on the Internet that are close to your time servers. That will ensure the shortest round-trip time or fewest number of hops (usually the same thing).

5. Enter the time servers in /etc/ntp.conf. Use multiple servers for greater reliability. Use the "prefer" keyword to select a preferred time server.

6. Start the NTP daemon. To check if the daemon is running, use the ntpq utility and enter "pe." If NTP is working properly, you'll see output for your peers that looks like the graphic on the left.

The "reach" column should show 377 for reachable servers.

7. Wait for the NTP daemon to synchronize. If you're in a big hurry, fire up packet sniffing using tcpdump udp Port 123 and look for traffic to and from your NTP peers. If you don't see traffic to and from the NTP servers, there could be several reasons for the failure, such as no domain-name resolution or firewall problems.