Using Network Time Protocol (NTP) with NetWare 5
Articles and Tips: article
Managing Director
Connectotel, London, UK
01 Jul 1999
Thanks to Vithalprasad Gaitonde of Novell India for his assistance in the preparation of this AppNote.
If you've been wondering what Network Time Protocol is and how it compares with NetWare's TIMESYNC protocol, this AppNote has got the answers.
- Introduction
- What is NTP?
- NTP Compared with NetWare's Classic TIMESYNC Protocol
- Using NTP with NetWare
- Troubleshooting NTP
- Conclusion
- Additional Information
Introduction
Time synchronization is necessary to provide accurate time throughout the Novell NetWare network. For Novell Directory Services (NDS), the provision of a uniform, accurate time is necessary to ensure that directory services operations proceed in an orderly fashion. Accurate time may be necessary for other reasons in a networked environment, including database synchronization, tape backup, compression and archiving routines.
Time synchronization may be achieved in a network using three main methods :
Voted time synchronization where the computers reach a consensus on what they believe the current time should be.
Forced time synchronization where a master-slave model is used such that the "master" system dictates the current time to the "slave" systems.
Hybrid model using a combination of the voted and forced methods.
This AppNote explains what Network Time Protocol (NTP) is and how it compares with NetWare's classic TIMESYNC protocol. It then discusses how to use NTP with NetWare 5 and provides tips for troubleshooting NTP-related problems.
What is NTP?
NTP, the Network Time Protocol, was first described by Dr. David Mills in the Request for Comments (RFC) document 958, "Network Time Protocol (NTP)" dated 1 September 1985. This RFC was produced subsequent to experiments which Dr. Mills had carried out on time synchronization, which are described in the documents RFC 957 "Experiments in network clock synchronization" and RFC 956 "Algorithms for synchronizing network clocks" both also dated 1 September 1985.
As with many of the other Internet protocols, it was through this investigative work that NTP was developed, first as a research project and subsequently as an Internet standard. The current NTP version, version 3, is documented in RFC 1305 of March 1992 and is a proposed Internet standard. NTP is implemented by vendors on many different platforms including UNIX, NetWare, Windows NT, and Apple Macintosh.
NTP provides the means for networked computers to serve and obtain accurate time on the Internet. An NTP "Client" is a computer which obtains its time from a time source. An NTP "Server" is the computer which provides an accurate source of time.
Stratum
NTP allows determination of the accuracy of an NTP server using the concept of the server's stratum. Stratum 1 NTP servers generally have a directly-attached atomic clock device and are considered to be the most accurate time servers. There are around 70 publically accessible stratum 1 servers available on the Internet.
Servers at stratum 2 provide less accurate time. Stratum values below 2 are used to indicate progressively less accurate time servers. In most cases, either stratum 1 or stratum 2 servers will be used as an NTP time source.
For details on servers which can provide time at Stratum 1 or Stratum 2, see the "Additional Information" section at the end of this AppNote.
Rules of Engagement
When using publically available NTP servers, it is necessary to be aware of certain rules of engagement which are in place to ensure courteous use of these public services. For current information about these rules for public time servers, visit the following URL:
http://www.eecis.udel.edu/~mills/ntp/servers.htm
NTP Compared with NetWare's Classic TIMESYNC Protocol
TIMESYNC.NLM provides a Novell-proprietary time synchronization service which has been available on NetWare since NetWare 4.0 was released in 1993. TIMESYNC NLM is actually an adaptation of NTP and uses similar algorithms to account for network delay when obtaining time from a time source. However, NTP as a protocol is quite a heavyweight. Therefore, when Novell originally created the time synchronization protocol used by NetWare in TIMESYNC, some features were omitted to make it more practical and simple to use.
Some of the features in the NTP protocol definition which are not present in TIMESYNC NLM are:
Leap second insertion: At regular intervals, clocks need to be compensated by inserting a leap second to the clock time.
Drift compensation: NTP keeps track of the pattern of changes to the clock, and over a period of time it computes a drift compensation factor that is applied to the clock.
Clock filtering and clock selection algorithms: NTP uses fairly complex algorithms to assess the reliability of each of the time sources in its list of time sources and selects only those which are considered to be reliable.
Authentication: NTP can use authentication to ensure the integrity of the time source. TIMESYNC NLM, which has been originally designed for use within the Intranet, trusts all time sources.
NTP is quite strict while considering a time source as a contender for obtaining time. If a time source is more than 1000 seconds (about 17 minutes) away from the local clock, NTP rejects the time source as being unreliable. The time source is labelled an "insane" time source and is not used in NTP exchanges.
NTP never corrects time directly. The time polled is given as a feedback to the clock, so that the clock corrects its time. This is in contrast to TIMESYNC, where the difference in time is gradually applied to the local clock. Typically, TIMESYNC.NLM tries to correct time within one polling interval (the default polling interval is 10 minutes). As a consequence of this approach, TIMESYNC is able to synchronize time in a network much more quickly, whereas NTP will usually take longer to achieve synchronization.
Using NTP with NetWare
Prior to the release of an NTP-capable TIMESYNC.NLM, Novell previously provided NTP.NLM with the shipping version of NetWare 5. It is now recommended that TIMESYNC.NLM be used in preference to NTP.NLM. NTP.NLM met some specific customer needs when it was introduced, but is much less robust than TIMESYNC.NLM.
Novell has recently enhanced TIMESYNC.NLM to provide both NTP client and server capability. TIMESYNC.NLM version 5.08 or later provides these facilities. As of May 1999, the latest 5.09 version of TIMESYNC.NLM is part of the file NW5SP2.EXE (NetWare 5 Service Pack 2), which is available for download from the Novell Support Connection Web site at:
TIMESYNC.NLM 5.09 includes these features:
A comprehensive collection of set parameters
Easy configuration
Operation over IPX and/or TCP/IP protocols
Automatic discovery of time sources when using IPX
Interoperability with NetWare 4.x and NetWare 5
NTP Client and Server capability
TIMESYNC.NLM Differences in NetWare 5
TIMESYNC.NLM in NetWare 4.x could only use IPX as its communication protocol. To advertise the presence of Time Synchronization services, the Service Advertising Protocol (SAP) was used. This protocol relies on periodic network broadcasts to advertise services.
TIMESYNC.NLM in NetWare 5 has been enhanced to work over TCP/IP or over IPX. This implies that if you have a network comprising both pure IP and pure IPX servers, time can flow from IPX to IP and vice-versa. To provide this capability, at least one server on the network must be configured with both IP and IPX to provide translation between the two sides. You do not need the Migration Gateway solution for this purpose.
In TCP/IP-based NetWare networks, the Service Location Protocol (SLP) is often used to advertise and locate services. This is much less bandwidth intensive than SAP, but requires more administration. TIMESYNC.NLM has not yet been enhanced to perform automatic discovery of time servers over IP using SLP. However, this feature is expected to be available in NetWare 5 Service Pack 3 or later. For further information about SLP theory, see RFC 2165.
Apart from these differences in protocols, the operation of the core NetWare time synchronization algorithms in NetWare 4.x and NetWare 5 remain identical, with no differences at all in the packet format or time synchronization algorithms being used. Thus, NetWare 4.x servers and NetWare 5 servers running TIMESYNC.NLM can interoperate seamlessly.
Configuring a NetWare Server as an NTP Client
To configure the network for NTP, first identify the "root" time servers in the network.
If you have used the "Single Reference - Secondary" time synchronization model, the Single Reference server is considered to be the root.
If you have used the "Reference - Primary - Secondary" model, the Reference server and Primary servers together act as the root for serving time to the other servers in the network.
For an explanation of these time synchronization models, see the AppNote entitled "Time Synchronization in NetWare 4.x" referenced in the "Additional Information" section at the end of this AppNote.
After identifying the root servers, update them so that they obtain time from the NTP time source. This involves changing the following SET command, either using SET at the server console or the MONITOR.NLM utility:
SET TIMESYNC TIME SOURCE=10.1.1.1:123
(123 in this line indicates that the time source on 10.1.1.1 will be contacted on UDP port 123, which is used by NTP.)
As the entire network looks to the root time sources for time, this will ensure that the entire network takes time from the NTP time source.
Configuring a NetWare Server as an NTP Server
It is often desirable to achieve time synchronization in a mixed environment comprising platforms such as NetWare, UNIX, Windows NT, and mainframes. To achieve time synchronization in such an environment, it is necessary to use an open, standard protocol for time synchronization such as NTP. UNIX servers often have NTP built into the base operating system. NTP implementations are also available for Windows NT and Apple Macintosh computers, as well as many others.
After identifying and deploying an NTP implementation for your platform, you are ready to talk to other NTP sources, such as those on NetWare or other UNIX systems on your internal network or on the Internet.
TIMESYNC.NLM version 5.08 or later has the capability to provide time to an NTP client. This service is provided via a service which communicates on UDP port 123. If you want your UNIX machines to take time from a NetWare server, set up NTP on your UNIX machines with the IP address of the NetWare server. This is done by entering the following statement in the NTP configuration file (usually /etc/inet/ntp.conf) for the UNIX system:
server <DNS name or IP address of the NetWare server<
No changes in parameter settings are necessary on the NetWare server to enable it to act as an NTP server.
This enhancement enables TIMESYNC.NLM to understand NTP "wire format" so that the server may provide time to an NTP community. However, the NTP protocol specification (RFC 1305) also mandates several features such as leap second insertion and clock drift correction. These are considered heavyweight and have therefore not been included in this enhancement, as mentioned previously in this AppNote.
NTP Fault Tolerance
Fault tolerance for NTP on NetWare may be achieved by configuring TIMESYNC.NLM with multiple time sources. The result will be that if one server cannot be contacted for any reason, the time can be obtained from other servers in the time source list.
Here is an example of using more than one time source. Note the use of the semicolon to separate the time sources.
SET TIMESYNC TIME SOURCE=10.1.1.1:123;10.1.1.2:123;
When using TIMESYNC.NLM 5.08 or 5.09, DNS names cannot currently be used in the list of time sources. Enhancements to TIMESYNC.NLM, available in a NetWare 5 Service Pack 3 or later, will be able to use DNS names.
Troubleshooting NTP
As NTP uses UDP port 123, it is necessary for traffic on that port to be allowed freely across your network. If you have firewalls or filtering routers in place between your network and the Internet and you are using NTP, UDP port 123 should be permitted to cross the boundary to the Internet.
To determine whether NTP is operating correctly, two debugging commands may prove useful: time synchronization debugging and TCP/IP debugging.
Time Synchronization Debugging
To enable time synchronization debugging, use the command:
SET TIMESYNC DEBUG=7
This command will enable a time synchronization debugging screen showing the interaction between NetWare time servers on the internal network, as well as communication with external NTP time sources.
To disable time synchronization debugging, use the command:
SET TIMESYNC DEBUG=0
TCP/IP Debugging
TCP/IP debugging allows every TCP/IP packet passing in and out of the server to be shown at the system console for troubleshooting purposes. To enable TCP/IP debugging, use the command:
SET TCP IP DEBUG=1
An example TCP/IP debug screen is shown in Figure 1. With TCP/IP debugging enabled, you will see pacdkets shown on port 123 whenever an NTP request or reply is transmitted or received.
Figure 1: An example of the TCP/IP debug screen.
To disable TCP/IP debugging, use the command:
SET TCP IP DEBUG=0
Troubleshooting Tools
A number of tools are available on the Internet to assist with troubleshooting of NTP configurations. Two such tools which may be useful are:
ntpq (NTP Query), available at:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/ntpq.htm
ntptrace, available at:
http://www.eecis.udel.edu/~ntp/ntp_spool/html/ntptrace.htm
Conclusion
As can be seen from this AppNote, the addition of NTP client and server capability to TIMESYNC.NLM has provided an important benefit for users of NetWare 5. Whereas previously the network administrator had to purchase third-party tools to provide external time synchronization, it is now possible to provide synchronization using the Novell-provided TIMESYNC.NLM program.
Additional Information
Further information about NTP and time synchronization in NetWare may be found in the Novell AppNotes, RFCs, and Web resources listed below. If you find additional useful sources of information on this topic, please contact the author of this AppNote via e-mail at Marcus_Williamson@ibm.net.
Novell AppNotes
"Time Synchronization in NetWare 4.x" by Steve Winn, November 1993. This AppNote remains the definitive guide to the general use of Time Synchronization for users of NetWare.
"Time in the NetWare Environment" by Marcus Williamson, January 1994. This AppNote contains an early version of the "Time Synchronization Solutions Guide" mentioned below, as well as detailed explanation of how NetWare uses time at a low level.
RFCs
RFC 1305 "Network Time Protocol (Version 3) Specification, Implementation." David L. Mills. March 1992. Format: TXT=307085 bytes. Obsoletes RFC 0958, RFC 1059, RFC 1119. Status: Draft Standard.
RFC 1129 "Internet time synchronization: The Network Time Protocol." D.L. Mills. Oct-01-1989. Format: TXT=298, PS=551697 bytes. Status: Unknown.
RFC 1128 "Measured performance of the Network Time Protocol in the Internet system." D.L. Mills. Oct-01-1989. Format: TXT=314, PS=633742 bytes. Status: Unknown.
RFC 1119 "Network Time Protocol (version 2) specification and implementation." D.L. Mills. Sep-01-1989. Format: TXT=143, PS=518020 bytes. Obsoletes RFC 0958, RFC 1059. Obsoleted by RFC 1305. Also STD 0012. Status: Standard.
RFC 1059 "Network Time Protocol (version 1) specification and implementation." D.L. Mills. Jul-01-1988. Format: TXT=140890 bytes. Obsoletes RFC 0958. Obsoleted by RFC 1119, RFC 1305. Status: Unknown.
RFC 0958 "Network Time Protocol (NTP)." D.L. Mills. Sep-01-1985. Format: TXT=30723 bytes. Obsoleted by RFC 1059, RFC 1119, RFC 1305. Status: Unknown.
RFC 0957 "Experiments in network clock synchronization." D.L. Mills. Sep-01-1985. Format: TXT=68952 bytes. Status: Unknown.
RFC 0956 "Algorithms for synchronizing network clocks." D.L. Mills. Sep-01-1985. Format: TXT=67387 bytes. Status: Unknown.
Web Resources
Information on Time and Frequency Services:
NTP Home Page.
Time Synchronization Solutions Guide (documents third-party solutions for synchronizing time using modem, radio, GPS and Internet-based time sources):
Newsgroup for discussion of NTP and related matters:
news://comp.protocols.time.ntp
Public NTP Stratum 1 servers (provides a list of publically available servers providing time at stratum 1):
Public NTP Stratum 2 servers (provides a list of publically available servers providing time at stratum 2):
International Organization of Internet Clock Watchers (describes a possible future project for providing a fault tolerant matrix of NTP servers available throughout the Internet):
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.