Network Computingwww.networkcomputing.com

Administrators building an NTP-based time infrastructure have three choices: obtain an external time source (e.g., GPS) to create a stratum-1 server, synchronize internal time servers to publicly available ones on the Internet, or designate a machine or group of machines as time authorities. The first two options will provide for an extremely accurate and UTC-synchronized network. The third can still provide for a synchronized network, but it may be a far cry from UTC, depending on the time sources used.

For example, you could assign an arbitrary stratum number to a group of NTP servers that use their internal clocks as time sources, and never query a UTC-based time server. While your servers may synchronize to each other properly, if they are all off by exactly 69 minutes, your entire network will be off by 69 minutes. If maintaining time relative to the rest of the world is important, consider synchronizing to an accurate UTC-based time source.

Rather than obtain and support the equipment necessary for a UTC-based stratum-1 time server, many choose to synchronize to existing time servers residing on the Internet. Administrators may be tempted to find the nearest set of stratum-1 time servers to which to synchronize, but this is usually unnecessary and is often considered poor etiquette. Stratum-1 servers provide an extremely accurate time source, but only organizations with an acute need for accuracy or those hosting public stratum-2 servers likely require such precision. The numerous stratum-2 and stratum-3 time servers on the Internet are fully sufficient for most implementations.

To achieve high accuracy and reliability, typical NTP configurations use multiple, geographically dispersed servers. Configuring your primary time servers to synchronize from multiple Internet-based sources will allow for greater precision and reduce the chances for failure. However, should an Internet outage cut off the time servers from their time sources, you can fall back on some configuration options that will provide continued stability.

One method configures internal time servers to use each other as "peers." An NTP time server configured as a peer not only will service synchronization requests, it also will allow itself to be synchronized. While not as precise as querying a set of UTC-based stratum-1 servers, having a few internal time servers as peers will keep things pretty tight.

Bringing Clients on Board Once you select a model for creating time servers, another infrastructure decision awaits you: the method of mass time distribution. Having a few dozen servers using NTP is one thing; having thousands of clients asking what time it is quite another. In most environments, workstation time is more of a luxury than a necessity. Most Windows machines can use NT or NetWare's login-script capabilities to pull time from local file servers. While less accurate than NTP, native client synchronization methods usually allow the workstation to be synchronized within a second or so of the server's time. In addition, using login scripts and native services is far easier to implement.

Should millisecond accuracy be required at the end-user level, administrators can choose client-to-server-based, multicast-based or broadcast-based synchronization. While all three require NTP clients, the multicast method is preferred for networks of more than a couple hundred workstations. Smaller networks or networks not multicast-capable may choose to configure client/server relationships, while broadcast-based NTP deployments will work locally. Many administrators of large networks choose to use NTP on their servers and time-critical applications, and stick to login-scripting functionality for workstations.

Several Unix versions, including HP-UX, Solaris and Digital, ship with an NTP package. Unix administrators also can download the latest implementations. The NTP package maintained at the University of Delaware, simply called "NTP" (the successor to the more popular xntp package), is in its fourth version and active development continues. NTPD, the daemon that runs as the time server process, supports access control using IP address ranges, authentication using DES encryption, advanced logging and many other features not found in other implementations.

Although it's not shipping native within NT, TimeServ, which can be found in the NT Server Resource Kit, can be installed as a service. TimeServ supports NTP along with a host of other time-based services. A good resource for this implementation is the author's Web site: home1.gte. net/dougho/TimeServ.html. However, you can't download TimeServ there; you have to buy the resource kit from Microsoft. But the version on the resource kit is old, so be sure you download the patch from Microsoft's FTP site.

On the NetWare front, only recently has Novell launched native support for NTP. While time synchronization has been important in NetWare deployments since NDS was introduced, Novell has always relied on timesync for its synchronization needs. However, NetWare 5 introduces NTPD.NLM, a full-fledged NTP server. While NDS still relies on timesync, using NTPD on NetWare 5 allows administrators to intertwine the two and still support a standards-based time infrastructure. Novell clients (not using NTP) can synchronize time to file servers using the "SET_TIME ON" parameter within the login scripts.

Greg Shipley is a Chicago-based consultant. Send your comments on this article to him at gshipley@neohapsis.com.