The Network Time Protocol (NTP) synchronizes time and coordinates time distribution throughout a TCP/IP network. NTP provides accurate and dependable timekeeping for hosts on TCP/IP networks. TCP/IP Services NTP software is an implementation of the NTP Version 4 specification and maintains compatibility with NTP Versions 1, 2, and 3.

Time synchronization is important in client/server computing. For example, systems that share common databases require coordinated transaction processing and timestamping of instrumental data.

NTP provides synchronization that is traceable to clocks of high absolute accuracy and avoids synchronization to clocks that keep incorrect time.

This chapter reviews key concepts and describes:

• How to start up and shut down NTP ( Section 13.2)
• How to configure the NTP host ( Section 13.3)
• How to configure the host as a backup time server ( Section 13.4)
• NTP event logging ( Section 13.5)
• How to configure NTP authentication ( Section 13.6)
• How to use NTP utilities ( Section 13.7)
• How to solve NTP problems ( Section 13.8)

Synchronized timekeeping means that hosts with accurate system timestamps send time quotes to each other. Hosts that run NTP can be either time servers or clients, although they are often both servers and clients.

NTP does not attempt to synchronize clocks to each other. Rather, each server attempts to synchronize to Coordinated Universal Time (UTC) using the best available source and the best available transmission paths to that source. NTP expects that the time being distributed from the root of the synchronization subnet will be derived from some external source of UTC (for example, a radio clock).

If your network is isolated and you cannot access other NTP servers on the internet, you can designate one of your nodes as the reference clock to which all other hosts will synchronize.

13.1.1 Time Distributed Through a Hierarchy of Servers

In the NTP environment, time is distributed through a hierarchy of NTP time servers. Each server adopts a stratum that indicates how far away it is operating from an external source of UTC. NTP times are an offset of UTC. Stratum 1 servers have access to an external time source, usually a radio clock. A stratum 2 server is one that is currently obtaining time from a stratum 1 server; a stratum 3 server gets its time from a stratum 2 server; and so on. To avoid long-lived synchronization loops, the number of strata is limited to 15.

Stratum 2 (and higher) hosts might be company or campus servers that obtain time from some number of primary servers and provide time to many local clients. In general:

• Lower-strata hosts act as time servers.
• Higher-strata hosts are clients that adjust their time clocks according to the servers.

Internet time servers are usually stratum 1 servers. Other hosts connected to an internet time server have stratum numbers of 2 or higher and can act as time servers for other hosts on the network. Clients usually choose one of the lowest accessible stratum servers from which to synchronize.

13.1.2 How Hosts Negotiate Synchronization

The identifying stratum number of each host is encoded within UDP datagrams. Peers communicate by exchanging these timestamped UDP datagrams. NTP uses these exchanges to construct a list of possible synchronization sources, then sorts them according to stratum and synchronization distance. Peers are accepted or rejected, leaving only the most accurate and precise sources.

NTP evaluates any new peer to determine whether it qualifies as a new (more suitable) synchronization source.

NTP rejects the peer under the following conditions:

• The peer is not synchronized.
• The stratum is higher than the current source's stratum.
• The peer is synchronized to the local node.

NTP accepts the peer under the following conditions:

• There is no current time source.
• The current source is unreachable.
• The current source is not synchronized.
• The new source's stratum is lower than the current source.
• The new source's stratum is the same as the current source, but its distance is closer to the synchronization source by more than 50 percent.

The OpenVMS system clock is maintained as a software timer with a resolution of 100 nanoseconds, updated at 10-millisecond intervals. A clock update is triggered when a register, loaded with a predefined value, has decremented to zero. Upon reaching zero, an interrupt is triggered that reloads the register, and the process is repeated.

The smaller the value loaded into this register, the more quickly the register reaches zero and triggers an update. Consequently, the clock runs more quickly. A larger value means more time between updates; therefore, the clock runs more slowly. A clock tick is the amount of time between clock updates.

13.1.4 How NTP Makes Adjustments to System Time

Once NTP has selected a suitable synchronization source, NTP compares the source's time with that of the local clock. If NTP determines that the local clock is running ahead of or behind the synchronization source, NTP uses a general drift mechanism to slow down or speed up the clock as needed. NTP accomplishes this by issuing a series of new clock ticks. For example, if NTP detects that the local clock is drifting ahead by +0.1884338 second, it issues a series of new ticks to reduce the difference between the synchronization source and the local clock.

If the local system time is not reasonably correct, NTP does not set the local clock. For example, if the new time is more than 1000 seconds off in either direction, NTP does not set the clock. In this case, NTP logs the error and shuts down.

NTP maintains a record of the resets it makes along with informational messages in the NTP log file, TCPIP$NTP_RUN.LOG. For details about event logging and for help interpreting an NTP log file, see Section 13.5.

13.1.5 Configuring the Local Host

The system manager of the local host, determines which network hosts to use for synchronization and populates an NTP configuration file with a list of the participating hosts.

NTP hosts can be configured in any of the following modes:

• Client/server mode
  This mode indicates that the local host wants to obtain time from the remote server and will supply time to the remote server. This mode is appropriate in configurations involving a number of redundant time servers interconnected through diverse network paths. Internet time servers generally use this mode.
  Indicate this mode with a peer statement in the configuration file, as shown in the following example:

  peer 18.72.0.3

• Client mode
  This mode indicates that the local host wants to obtain time from the remote server but will not provide time to the remote server. Client mode is appropriate for file server and workstation clients that do not provide synchronization to other local clients. A host with higher stratum generally uses this mode.
  Indicate client mode with the server statement in the configuration file, as shown in the following example:

  server 18.72.0.3

• Broadcast mode
  This mode indicates that the local server will send periodic broadcast messages to a client population at the broadcast/multicast address specified. This specification normally applies to the local server operating as a sender.
  Indicate this mode with a broadcast statement in the configuration file, as shown in the following example:

  broadcast 18.72.0.255

• Multicast mode
  A multicast client is configured using the broadcast statement, but with a multicast group (class D) address instead of a local subnet broadcast address. However, there is a subtle difference between broadcasting and multicasting. Broadcasting is specific to each interface and local subnet address. If more than one interface is attached to a machine, a separate broadcast statement applies to each one.
  IP multicasting is a different paradigm. A multicast message has the same format as a broadcast message and is configured with the same broadcast statement, but with a multicast group address instead of a local subnet address. By design, multicast messages travel from the sender via a shortest-path or shared tree to the receivers, which might require these messages to emit from one or all interfaces but to carry a common source address. However, it is possible to configure multiple multicast group addresses using multiple broadcast statements. Other than these differences, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than can ordinary IP unicast messages.
  The Internet Assigned Number Association (IANA) has assigned multicast group address 224.0.1.1 to NTP, but you should use this address only where the multicast span can be reliably constrained to protect neighbor networks. In general, you should use group addresses that have been given out by your administrator, as described in RFC 2365, or GLOP group addresses, as described in RFC 2770.
• Manycast mode
  Manycasting is an automatic discovery and configuration paradigm new to NTP Version 4. It is intended as a means for a multicast client to survey the nearby network neighborhood for cooperating manycast servers, to validate them using cryptographic means, and to evaluate their time values with respect to other servers in the vicinity. The intended result is that each manycast client mobilizes client associations with the best three of the available manycast servers and automatically reconfigures to sustain this number of servers if one or more fail.
  A persistent manycast client association is configured using the server statement, but with a multicast (class D) group address instead of an ordinary IP (class A, B, C) address. There can be as many manycast client associations as different group addressses.
  Manycast servers configured with the manycastserver statement listen on the specified group address for manycast client messages. Note the distinction between a manycast client, which is configured with a server statement, and a manycast server, which is configured with a manycastserver statement.
  If a manycast server is in range of the current time-to-live and is synchronized to a valid source and operating at a stratum level equal to or lower than that of the manycast client, the server replies to the manycast client message with an ordinary server-mode message.
  The manycast client that receives this message mobilizes an ephemeral client association as in ordinary client/server mode, according to the matching manycast client template. Then the client polls the server in burst mode at its unicast address in order to set the host clock reliably and to validate the source. The client runs the NTP intersection and clustering algorithms, which discard all but the best three associations. The surviving associations then continue in ordinary client/server mode.
• Burst mode
  Two burst modes can be enabled in client/server mode using the server statement and the iburst and burst keywords. In either mode, a single poll initiates a burst of eight client messages at intervals randomized over a range of 1 to 4 seconds. However, the interval between the first message and the second message is increased to about 16 seconds in order for a dialup modem to complete a call, if necessary.
  Received server messages update the NTP Version 4 clock filter, which selects the best (most accurate) time values. When the last client message in the burst is sent, the next received server message updates the system variables and sets the system clock in the usual manner, as if only a single client/server cycle had occurred. The result is not only a rapid and reliable setting of the system clock, but also a considerable reduction in network jitter.
  The iburst keyword can be configured when it is important to set the clock quickly, such as when an association is either first mobilized or first becomes reachable, or when the network attachment requires an initial calling or training procedure. The burst is initiated only when the server first becomes reachable. It results in good accuracy with intermittent connections typical of PPP and ISDN services. Outlyers caused by initial dialup delays and other factors are avoided, and the client sets the clock within 30 seconds after the first message.
  The burst keyword can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training procedure. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. It should be used only if the poll interval is expected to settle to values equal to or greater than 1024 seconds.

The NTP service can be shut down and started independently of TCP/IP Services. The following files are provided:

• SYS$STARTUP:TCPIP$NTP_STARTUP.COM allows you to start the NTP service.
• SYS$STARTUP:TCPIP$NTP_SHUTDOWN.COM allows you to shut down the NTP service.

To preserve site-specific parameter settings and commands, create the following files. These files are not overwritten when you reinstall TCP/IP Services:

• SYS$STARTUP:TCPIP$NTP_SYSTARTUP.COM can be used as a repository for site-specific definitions and parameters to be invoked when the NTP service is started.
• SYS$STARTUP:TCPIP$NTP_SYSHUTDOWN.COM can be used as a repository for site-specific definitions and parameters to be invoked when the NTP service is shut down.

The NTP configuration file TCPIP$NTP.CONF contains a list of hosts your system will use for time synchronization. Before configuring your host, you must do the following:

1. Select time sources.
2. Obtain the IP addresses or host names of the time sources.
3. Obtain the version number of NTP that the hosts are running.

To ensure reliable synchronization, select multiple time sources that you are certain provide accurate time and that are synchronized to an Internet time server.

To minimize common points of failure, avoid synchronizing the following:

• The local host to another peer at the same stratum, unless the latter is receiving time from a lower stratum source to which the local host cannot connect.
• More than one host in a particular administrative domain to the same time server outside that domain.

To simplify configuration file maintenance, avoid configuring peer associations with higher-stratum servers.

13.3.1 Creating the Configuration File

To create a configuration file for your local host, edit a copy of the file TCPIP$NTP.TEMPLATE (located in SYS$SPECIFIC:[TCPIP$NTP]) to add the names of participating hosts, then save the file as SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.CONF. This file is not overwritten when you install subsequent versions of TCP/IP Services.

In the following configuration statements, the various modes are determined by the statement keyword and the type of the required IP address. Addresses are classsed by type as ( s ) a remote server or peer (IP class A, B, and C), ( b ) the broadcast address of a local interface, ( m ) a multicast address (IP class D), or ( r ) a reference clock address (127.127.x.x).

NTP configuration statements are formatted as follows:

• peer address [key ID] [version number] [prefer] [minpoll interval] [maxpoll interval]
  server address [key ID] [version number] [prefer ][burst] [iburst] [minpoll interval] [maxpoll interval]
  broadcast address [key ID] [version number][minpoll interval][ttl nn]
  manycastclient address [key ID] [version number][[minpoll interval] [maxpoll interval][ttl nn]
  These four statements specify the time server name or address to be used and the mode in which to operate. The address can be either a DNS name or an IP address.
  • peer --- For type s addresses only, this statement mobilizes a persistent symmetric-active mode association with the specified remote peer. This statement should not be used for type b , type m , or type r addresses.
  • server --- For type s and type r addresses only. This statement mobilizes a persistent client mode association with the specified remote server or local reference clock. This statement should not be used for type b or type m addresses.
  • broadcast --- For type b and type m addresses only. This statement mobilizes a persisent broadcast mode association. Multiple statements can be used to specify multiple local broadcast interfaces (subnets) or multiple multicast groups. Note that local broadcast messages go only to the interface associated with the subnet specified, but multicast messages go to all interfaces.
  • manycastclient --- For type m addresses only. This statement mobilizes a manycast client mode association for the multicast address specified. In this case, a specific address must be supplied that matches the address used on the manycastserver statement for the designated manycast servers.
    The manycastclient statement specifies that the local server is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified address and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the server statement. The remaining servers are discarded as if never heard.
  
  The following table describes the options to the NTP configuration statements:

  Option	Description
  key ID	For all packets sent to the address, includes authentication fields encrypted using the specified key identifier, an unsigned 32-bit integer. The default is no encryption.
  version number	Specifies the version number to be used for outgoing NTP packets. Versions 1, 2, 3, and 4 are the choices. The default is 4.
  prefer	Marks the server as preferred. This host will be chosen for synchronization from a set of correctly operating hosts.
  burst	When the server is reachable and at each poll interval, send a burst of eight packets instead of the usual one packet. The interval between the first and the second packets is about 16 seconds to allow a modem call to complete, while the interval between the remaining packets is about 2 seconds. This is designed to improve timekeeping quality with the server command and s addresses.
  iburst	When the server is unreachable and at each poll interval, send a burst of eight packets instead of the usual one. As long as the server is unreachable, the spacing between packets is about 16 seconds to allow a modem call to complete. Once the server is reachable, the interval between packets is about 2 seconds. This is designed to speed the initial synchronization acquisition with the server command and s addresses.
  minpoll interval	Specifies the minimum polling interval for NTP messages, in seconds to the power of 2. The allowable range is 4 (16 seconds) to 14 (16384 seconds), inclusive. This option is not applicable to reference clocks. The default is 6 (64 seconds).
  maxpoll interval	Specifies the maximum polling interval (in seconds), for NTP messages. The allowable range is 4 (16 seconds) to 14 (16384 seconds) inclusive. The default is 10 (1024 seconds). This option does not apply to reference clocks.
  ttl nn	Specifies the time-to-live for multicast packets. Used only with broadcast and manycast modes.

  
  
• broadcastclient
  This statement enables the reception of broadcast server messages to local interface (type b ) addresses. Upon receiving a message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters broadcastclient mode, in which it listens for and synchronizes to succeeding broadcast messages. Note that to avoid accidental or malicious disruption in this mode, both the server and client should use authentication and the same trusted key and key identifier.
• broadcastdelay seconds
  The broadcast and multicast modes require a special calibration to determine the network delay between the local and remote servers. Usually, this is done automatically by the initial protocol exchanges between the client and server. In some cases, the calibration procedure fails because of network or server access controls. This statement specifies the default delay to be used under these circumstances. Typically (for Ethernet), a number between 0.003 and 0.007 second is appropriate. When this statement is not used, the default is 0.004 second.
• multicastclient address
  This statement enables reception of multicast server messages to the multicast group addresses (type m ) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to suceeding multicast messages.
  Note that to avoid accidental or malicious disruption in this mode, both the server and client should use authentication and the same trusted key and key identifier.
• manycastserver address
  This statement enables reception of manycast client messages to the multicast group addresses (type m ) specified. At least one address is required. The Internet Assigned Number Association (IANA) has assigned multicast group address 224.0.1.1 to NTP, but you should use this address only where the multicast span can be reliably constrained to protect neighbor networks. In general, you should use group addresses that have been given out by your administrator, as described in RFC 2365, or GLOP group addresses, as described in RFC 2770. Note that to avoid accidental or malicious disruption in this mode, both the server and client should use authentication and the same trusted key and key identifier.
• driftfile file-specification
  This statement specifies the name of the file used to record the frequency offset of the local clock oscillator. If the file exists, it is read at startup to set the initial frequency offset, and then is updated hourly with the current frequency computed by the NTP server.
  If the file does not exist or if the driftfile statement is not specified in the configuration file, the initial frequency offset is assumed to be zero. If the file does not exist but the driftfile keyword is specified without a parameter, the default, SYS$SPECIFIC:[TCPIP$NTP]TCPIP$NTP.DRIFT is used.
  In these cases, it might take some hours for the frequency to stabilize and for the residual timing errors to subside.
  The drift file TCPIP$NTP.DRIFT consists of a single floating-point number that records the frequency of the offset measured in parts per million (ppm).
• enable auth | bclient | monitor | ntp | stats
  disable auth | bclient | monitor | ntp | stats
  These statements enable and disable the following server options:

  auth	Controls synchronization with unconfigured peers only if the peer has been correctly authenticated using a trusted key and key identifier. By default, auth is enabled.
  bclient	Controls the server to listen for messages from broadcast or multicast servers. By default, bclient is disabled.
  monitor	Controls the monitoring facility. By default, monitor is enabled.
  ntp	Enables the server to adjust its local clock by means of NTP. If disabled, the local clock free runs at its intrinsic time and frequency offset. This statement is useful in case the local clock is controlled by some other device or protocol and NTP is used only to provide synchronization to other clients. In this case, the local clock driver can be used to provide this function and also certain time variables for error estimates and leap indicators. The default for this flag is enable.
  stats	Enables the statistics facility. By default, stats is enabled.

• logconfig configkeyword
  This statement controls the amount and type of output written to the system log file. By default, all output is turned off. All configkeyword keywords can be prefixed with a plus sign (+) to add messages or a minus sign (-) to remove messages. Messages can be controlled in four classes ( clock , peer , sys , and sync ). Within these classes, four types of messages can be controlled. Informational messages ( info ) control configuration information. Event messages ( events ) control logging of events (reachability, synchronization, alarm conditions). Statistics messages ( statistics ) control statistical output. The final message group is the status ( status ) messages. This message group describes mainly the synchronization status.
  Configuration keywords are formed by concatenating the message class with the event class. The all prefix can be used instead of a message class. A message class can also be followed by the all keyword to enable or disable all messages of the respective message class. Therefore, a minimal log configuration might look like the following example:

  ---

  Previous

  Next

  Contents

  Index