Network Time Protocol (NTP) is a protocol designed to time-synchronize a network of machines. NTP runs on UDP, which in turn runs on IP. NTP Version 3 (NTPv3) is documented in RFC 1305.
An NTP network usually gets its time from an authoritative time source such as a radio clock or an atomic clock attached to a time server. NTP then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to the accuracy of within a millisecond of one another.
NTP uses the concept of a stratum to describe how many NTP hops away a machine is from an authoritative time source. A stratum 1 time server typically has an authoritative time source (such as a radio or atomic clock or a Global Positioning System [GPS] time source) directly attached, a stratum 2 time server receives its time via NTP from a stratum 1 time server, and so on.
NTP has two ways to avoid synchronizing to a machine whose time may not be accurate. NTP does not synchronize to a machine that is not in turn synchronized with the NTP. NTP compares the time reported by several machines and does not synchronize to a machine whose time is significantly different from others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers.
Our implementation of NTP does not support stratum 1 service; that is, you cannot connect to a radio or atomic clock (for some specific platforms, however, you can connect to a GPS time-source device). We recommend that the time service you derive for your network from the public NTP servers that are available in the IP Internet.
If the network is isolated from the Internet, our implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact the network has determined the time by using other means. Other machines can then synchronize to that machine via NTP.
A number of manufacturers include NTP software for their host systems and a publicly available version for systems running UNIX. This software also allows UNIX-derivative servers to acquire the time directly from an atomic clock, which would subsequently propagate time information along to Cisco devices.
The communication between machines running NTP (known as associations) are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible through exchange of NTP messages between each pair of machines with an association.
However, in a LAN environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity because each machine can be configured to send or receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is only one way.
The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two security mechanisms are available: an access-list-based restriction scheme and an encrypted authentication mechanism.
When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
NTP services are disabled on all interfaces by default.
NTP runs within IOS daemon (IOSd), which updates the time on the Linux kernel. Because the Linux kernel updates the hardware clock every 11 minutes, NTP does not interact with the hardware clock directly. So, the calendar-related commands need not be configured.
For more information about NTP, see the following sections:
Poll-Based NTP Associations
Networking devices running NTP can be configured to operate in variety of association modes when synchronizing time with reference time sources. A networking device can obtain time information on a network in two ways: by polling host servers and by listening to NTP broadcasts. This section describes the poll-based association modes. Broadcast-based NTP associations are described in "Broadcast-Based NTP Associations".
The following are the two most commonly used poll-based association modes:
- Client mode
- Symmetric active mode
The client and the symmetric active modes should be used when NTP is required to provide a high level of time accuracy and reliability.
When a networking device is operating in the client mode, the device polls its assigned time-serving hosts for the current time. The networking device then picks a host from among all the polled time servers to synchronize the time. Because the relationship that is established in this case is a client-host relationship, the host does not capture or use any time information sent by the local client device. This mode is most suited for file-server and workstation clients that are not required to provide any form of time synchronization to other local clients. Use the ntp server command to individually specify the time-serving hosts with which you want to synchronize your networking device and to set your networking device to operate in the client or symmetric active mode.
When a networking device is operating in the symmetric active mode, the device polls its assigned time-serving hosts for the current time and it responds to polls by its hosts. Because this is a peer-to-peer relationship, the host will also retain time-related information of the local networking device with which the host is communicating. This mode should be used when a number of mutually redundant servers are interconnected via diverse network paths. Most stratum 1 and stratum 2 servers on the Internet adopt this form of network setup. Use the ntp peer command to individually specify the time servers with which you want your networking device to consider synchronizing and set your networking device to operate in the symmetric active mode.
The specific mode that you should set on each of your networking devices depends primarily on the role that you want them to assume as a timekeeping device (server or client) and their proximity to a stratum 1 timekeeping server.
A networking device engages in polling when it is operating as a client or a host in the client mode or when the device is acting as a peer in the symmetric active mode. Although polling does not usually place a burden on memory and CPU resources such as bandwidth, an exceedingly large number of ongoing and simultaneous polls on a system can seriously impact the performance of a device or slow the performance of a given network. To avoid having an excessive number of ongoing polls on a network, you should limit the number of direct, peer-to-peer, or client-to-server associations. Instead, you should consider using NTP broadcasts to propagate time information within a localized network.
NTP Access Group
The access-list-based restriction scheme allows you to grant or deny certain access privileges to an entire network, a subnet within a network, or a host within a subnet. To define an NTP access group, use the ntp access-group command in global configuration mode.
The access group options are scanned in the following order, from least restrictive to the most restrictive:
- ipv4--Configures IPv4 access lists.
- ipv6--Configures IPv6 access lists.
- peer--Allows time requests and NTP control queries and allows the device to synchronize itself to a device whose address passes the access list criteria.
- serve--Allows time requests and NTP control queries but does not allow the device to synchronize itself to a device whose address passes the access list criteria.
- serve-only--Allows only time requests from a device whose address passes the access list criteria.
- query-only--Allows only NTP control queries from a device whose address passes the access list criteria.
If the source IP address matches the access lists for more than one access type, the first type is granted access. If no access groups are specified, all access types are granted to all devices. If access groups are specified, only the specified access types are granted access.
For details about NTP control queries, see RFC 1305 (NTP Version 3).
The encrypted NTP authentication scheme should be used when a reliable form of access control is required. Unlike the access-list-based restriction scheme that is based on IP addresses, the encrypted authentication scheme uses authentication keys and an authentication process to determine if NTP synchronization packets sent by designated peers or servers on a local network are deemed as trusted before the time information that they carry along with them is accepted.
The authentication process begins from the moment an NTP packet is created. Cryptographic checksum keys are generated using the message digest algorithm 5 (MD5) and are embedded into the NTP synchronization packet that is sent to a receiving client. After a packet is received by a client, the packet's cryptographic checksum key is decrypted and checked against a list of trusted keys. If the packet contains a matching authentication key, the time-stamp information that is contained within the packet is accepted by the receiving client. NTP synchronization packets that do not contain a matching authentication key are ignored.
In large networks, where many trusted keys must be configured, the Range of Trusted Key Configuration feature enables configuring multiple keys simultaneously.
It is important to note that the encryption and decryption processes used in NTP authentication can be very CPU-intensive and can seriously degrade the accuracy of the time that is propagated within a network. If your network setup permits a more comprehensive model of access control, you should consider the use of the access-list-based form of control instead.
After NTP authentication is properly configured, your networking device synchronizes with and provide synchronization only to trusted time sources.
The Network Time Protocol (NTP) subnet is sometimes isolated from local reference clocks or Internet clock servers. During this period of isolation, subnet servers and clients are synchronized to a common time scale. The local clock driver simulates a Coordinated Universal Time (UTC) source to provide a common time scale. A server connected to the driver directly or indirectly synchronizes the other hosts in the subnet.
Using a local clock driver may sometimes result in irrecoverable failures of the subnet, and maintaining redundancy using multiple servers is not feasible. The orphan mode feature, which does not have any such disadvantages, removes the need for a local clock driver. The orphan mode feature provides a single simulated UTC source with multiple servers and a seamless switching as servers recover from failure.
In private networks, one or multiple core servers operating at the lowest stratum is normally included. You must configure each of these servers as backups for other servers using symmetric or broadcast modes. Even if one core server reaches a UTC source, the entire subnet synchronizes to the simulating server. If none of the servers reach a UTC source, one of the servers, which is known as the orphan parent, can simulate a UTC source and serve as the simulated UTC source for all the other hosts, known as orphan children, in the subnet.
Use the ntp orphan stratum command to enable a host for orphan mode. The stratum argument is a value less than 16 and greater than any stratum value that occurs in the configured Internet time servers. However, you must provide sufficient headroom so that every subnet host dependent on the orphan children has a stratum value less than 16. If no associations for other servers or reference clocks are configured, you must set the orphan stratum value to 1.
An orphan parent operating at stratum 1 with no sources displays the reference ID LOOP. An orphan parent not operating at stratum 1 displays the UNIX loopback address 127.0.0.1. Ordinary NTP clients use a selection metric based on delay and dispersion, whereas orphan children use a metric computed from the IP address of each core server in the subnet. Each orphan child selects the orphan parent with the smallest metric as the root server.
The figure below illustrates how orphan mode is set up and a peer network is configured. In this peer network, two primary or secondary (stratum 2) servers are configured with reference clocks or public Internet primary servers, with each using symmetric modes. A server that loses all sources continuously synchronizes the local clock driver with other servers, thus backing up the server. Enable orphan mode only in core servers and orphan children.
|Figure 1 ||Orphan Mode Setup |
Prerequisites for Orphan Mode
To ensure smooth function of the orphan mode, you must configure each core server with available sources to operate at the same stratum. Configure the ntp orphan command in all the core servers and the orphan children. Configure each orphan child with all root servers.