|
|
This chapter describes how the Network Time Protocol (NTP) synchronizes a system clock with another time source. It contains the following sections:
For information about starting and stopping the NTP service, controlling access to it, and setting basic and communication options, see Chapter 2, "Configuring Services with the Cisco Service Manager."
In enterprise computing, isolated standalone processors are becoming less common. Some examples of the need for agreement about the time-of-day among involved processors are coordinated transaction processing and time-stamping of instrumental data. NTP, the Network Time Protocol, is a powerful utility for synchronizing system clocks over TCP/IP networks. It provides a precise time base for networked workstations and servers. NTP implements a version of the Network Time Protocol first described in RFC-958, "Network Time Protocol." Other RFCs for time synchronization include:
In the NTP model, a number of primary reference sources, synchronized by wire or radio to national standards, are connected to widely accessible resources, such as backbone gateways, and operated as primary time servers. NTP provides a protocol to pass timekeeping information from these servers to other time servers via the Internet and to cross-check clocks and correct errors arising from equipment or propagation failures. Local-net hosts or gateways, acting as secondary time servers, use NTP to communicate with one or more of the primary servers. In order to reduce the protocol overhead, the secondary servers distribute time to the remaining local-net hosts. For reliability, selected hosts are equipped with less accurate (and less expensive) radio clocks. These host are used for backup in case of failure of the primary and/or secondary servers or the communication paths between them.
The NTP subnet consists of a multiple redundant hierarchy of servers and clients, with each level in the hierarchy identified by a stratum number. This number specifies the accuracy of each server, with the topmost level (primary servers) assigned as 1 and each level downward (secondary servers) in the hierarchy assigned as one greater than the preceding level. Stratum 1 is populated with hosts with bus or serial interfaces to reliable sources of time, such as radio clocks, GPS satellite timing receivers, or atomic clocks. Stratum 2 servers might be company or campus servers that obtain time from some number of primary servers over Internet paths, and provide time to many local clients. The stratum 2 servers may be configured to peer with each other, comparing clocks and generating a synchronized time value.
NTP performs well over the non-deterministic path lengths of packet-switched networks, because it makes robust estimates of three key variables in the relationship between a client and a time server: network delay, dispersion of time packet exchanges (a measure of maximum clock error between the two hosts), and clock offset (the correction to apply to a client's clock to synchronize it). Clock synchronization at the 10-millisecond level over long distance (2000 km) WANs, and at the 1-millisecond level for LANs, is routinely achieved.
There is no provision for peer discovery or virtual-circuit management in NTP. Data integrity is provided by the IP and UDP checksums. No flow-control or retransmission facilities are provided or necessary. Duplicate detection is inherent in the processing algorithms.
NTP uses a system call on the local host to "slew" the local system clock by a small amount in order to keep the clock synchronized. If the local clock exceeds the "correct" time by preset threshold, then NTP uses a system call to make a step adjustment of the local clock.
There are a number of modes in which NTP servers can associate with each other. The mode of each server in the pair indicates the behavior the other server can expect from it. An "association" is formed when two peers exchange messages and one or both of them create and maintain an instantiation of the protocol machine. The association can operate in one of several modes: server, client, peer, and broadcast/multicast. The modes are further classified as active and passive. In active modes, the host continues to send NTP messages regardless of the reachability or stratum of its peer. In passive modes, the host sends NTP messages only as long as its peer is reachable and operating at a stratum level less than or equal to the host; otherwise, the peer association is dissolved.
Normally, one peer operates in an active mode (symmetric-active, client or broadcast/multicast modes), while the other operates in a passive mode (symmetric-passive or server modes), often without prior configuration. However, both peers can be configured to operate in the symmetric-active mode. An error condition results when both peers operate in the same mode, except for the case of symmetric-active mode. In this case, each peer ignores messages from the other, so that prior associations, if any, will be demobilized due to reachability failure.
When NTP is started on a system, it reads configuration information from the file ntp.cnf, which contains information about other NTP timeservers and host specific information. In CDDM, the CSM manager automatically generates and updates the configuration file based on values that you have entered via the NTP service Configuration tab.
When the NTP server first starts, it computes the error in the intrinsic frequency of the clock on the computer it is running on. It usually takes about a day or so to compute a good estimate of this (and it needs a good estimate to synchronize closely to its server). Once the initial value is computed, it changes by only small amounts during the course of continuous operation. The drift file (which you can specify via CSM) is the name of a file in which to store the current value of the frequency error so that, if the server is stopped and restarted, it can reinitialize itself to the previous estimate and avoid the day's worth of time it would take to recompute the frequency estimate. We recommend that you always specify a drift file in the NTP configuration.
The NTP subnet presently includes over 50 public primary servers synchronized directly to UTC by radio, satellite, or modem. Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are about 100 public secondary servers synchronized to the primary servers. These provide synchronization to a total in excess of 100,000 clients and servers on the Internet. The current lists are maintained in the List of Public NTP Servers page, which is updated frequently. There are numerous private primary and secondary servers not normally available to the public as well. For a list of public NTP servers and information about using them, consult the URL http://www.eecis.udel.edu/~ntp/ at the University of Delaware.
If your site is not connected to the Internet and does not have access to the public NTP servers, you can use one of your internal systems as an "authoritative" NTP server by configuring it to derive time from its own system clock. (Refer to the section "Configuring a Reference Clock" below.) Using this approach, you can declare one host in an isolated network as having the "correct" time so that other hosts on the network can synchronize
to it.
Some implementations of NTP allow you derive time directly from a "reference clock," a hardware clock on the local machine. This feature is currently unsupported in CDDM. However, you can configure your local system clock as a reference clock by specifying appropriate values in the fields within the Local Clock area of the NTP Config tab, as follows:
For the purposes of configuration, NTP treats reference clocks in a manner analogous to normal NTP peers. The entire suite of algorithms used to filter the received data, select the best clocks or peers, and produce a local clock correction are operative as with ordinary NTP peers. In this way, defective clocks can be detected and removed from the peer population. However, no packets are exchanged with a reference clock.
Table 9-1 describes the basic NTP configuration parameters.
| Parameter | Description | Default (if any) |
|---|---|---|
| Debuglevel | A number that specifies the amount of information contained in debugging messages. -1 is off, and each higher number, up to a maximum of 10, produces more output. | -1 (off) |
| Driftfile | The file in which NTP keeps a record of its clock frequency updates. | ntp.drift |
| Logclock | If enabled, NTP sends a message to the default Syslog log file each time it adjusts the logical clock. | Off |
| Passive | Specifies the Internet addresses of remote peers with which the NTP server associates in symmetric-passive mode. | None |
| Peer | Specifies the Internet addresses of remote peers with which the NTP server associates in symmetric-active mode. On UNIX systems, the local clock is configured as a peer, by default. | None |
| Precision | Specifies the precision of the local clock. A number that describes the resolution of the clock as a power of two. | .5 |
| Server | The Internet addresses of time servers with which to synchronize. | 128.102.16.10, 130,43.2.2 |
| Set-threshold | The maximum amount of time the NTP will "slew" the clock. If the clock threshold is off by more than this amount, NTP uses a system call on the host to reset the clock. The default value should not be changed. The maximum threshold is 6.0 seconds. | .5 |
| Trusting | If enabled, allows peers not specified in the NTP configuration to change the system clock. | On |
| Waytoobig | The maximum number of seconds that NTP will change the system clock. This parameter is used as a sanity check to prevent the system time from being changed a great deal. | 4000 |
Table 9-2 describes the local clock parameters.
| Parameter | Description | Default (if any) |
|---|---|---|
| Device Name | The name of the file that the clock is connected to. Currently, the only device supported is /dev/null. | /dev/null |
| Ref ID | A 32-bit code identifying a particular reference clock. Currently, the only code supported is LOCL. | LOCL |
| Stratum | An integer indicating the stratum of the local clock. The stratum is a measure of clock accuracy; the lower the number, the more accurate the clock. | 4 |
| Precision | The precision of the system clock. A number that describes the resolution of the clock as a power of two. | -6 |
| Psti/Local | Type of the clock. Currently, the only type supported is "local," which indicates the local time of the system | local |
This section contains procedures for connecting to, and obtaining time from, hosts on the Internet or your local network.
To specify the host(s) with which to synchronize in client mode:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 4 Enable the checkbox next to the Server label.
Step 5 Click the ... button next to the Server field.
Step 6 Enter the IP address of one or more remote hosts with which you want to synchronize.
Step 7 Click OK.
Step 8 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
To specify the host(s) with which to synchronize in symmetric-active mode:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Peer label.
Step 5 Click the ... button next to the Peer field.
Step 6 Enter the IP address of one or more remote hosts with which you want to synchronize.
Step 7 Click OK.
Step 8 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
A remote host specified as passive is not polled if the connection to that host is lost. If the remote host becomes available, it re-establishes communication with the NTP server.
To specify a host as passive:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Passive label.
Step 5 Click the ... button next to the Passive field.
Step 6 Enter the IP address of the remote hosts you want to specify for passive mode.
Step 7 Click OK.
Step 8 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
To configure the local system clock as a reference clock:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enter an appropriate stratum number in the Stratum field (in the Local Clock area), or use the default value.
Step 5 Enter an appropriate precision number in the Precision field, or use the default value.
Step 6 Choose Save Configuration from the File menu.
This configuration defines a "fake" peer to poll by checking the "local time." This definition causes NTP to think it is synchronized and to advertise the time to any other system that polls it.
Your changes take effect after you restart the NTP service.
This section describes options for controlling how NTP changes your system clock.
If NTP needs to adjust your system clock, it "slews" the clock by running it 10% faster or 10% slower to keep it synchronized. If your system clock is off by more than the specified length of time, NTP does not slew the system clock, but rather changes it directly.
To specify the maximum amount that your system clock can be off for NTP to slew the system clock:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Set-threshold label.
Step 5 Enter the maximum number of seconds NTP is allowed to slew the system clock in the Set-threshold field. The default value is .5 seconds.
Step 6 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
NTP includes a parameter that serves as a "sanity check" and limits how far NTP can change your system clock. To specify the maximum change NTP can make:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Waytoobig label.
Step 5 Enter the maximum number of seconds NTP can change your system clock in the Waytoobig field. The default value is 4000 seconds.
Step 6 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
You can specify the precision of your system clock by providing a number that describes the resolution of your system clock as a power of two. Choose the nearest power of two that is greater than the actual clock resolution. For example, for a clock with a resolution of
100 Hz, the precision would be 7 (27 is 128). The default value selected for your hardware should be correct.
 | Caution Do not change this parameter unless you are directed to do so by a Cisco customer support engineer. |
To specify the precision of your system clock:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Precision label.
Step 5 Enter the precision of your system clock in the Precision field.
Step 6 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
You can configure the NTP service to send a message to the default Syslog log file (MultiNet\log\info.log for Windows NT, or CSCOcddm/log/info.log for UNIX, found in the installation directory) every time it adjusts the logical clock. This is useful if you want to gather statistical information to analyze the logical clock behavior. The logical clock is the software clock maintained by the NTP protocol.
To configure the NTP service to send messages to the system log:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the Logclock checkbox.
Step 5 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
| Caution This file may grow very large very quickly. Cisco recommends that you log logical clock changes for debugging purposes only. |
NTP stores the drift compensation register in a file loaded at initialization and used to store updated drift values. To specify the path name of the drift file:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Driftfile label.
Step 5 Enter the path and file name of the drift file in the Driftfile field.
Step 6 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
By enabling the Trusting option, you can specify that NTP allow peers not specified in your NTP configuration to change your system clock. By default, trusting is disabled. To enable trusting:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Trusting label.
Step 5 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
You can specify the debug level at which the NTP service operates. Increasing the debug level provides progressively more detailed information in NTP messages. The default level is -1, which disables all message output, including operational messages. Each increase in level, up to a maximum of 10, produces more output.
To specify the debug level for the NTP server:
Step 1 Start the CSM.
Step 2 Choose NTP from the Available Services list.
Step 3 Select the Config tab.
Step 4 Enable the checkbox next to the Debuglevel label.
Step 5 Enter the debug level in the Debuglevel field.
Step 6 Choose Save Configuration from the File menu.
Your changes take effect after you restart the NTP service.
|
|
