NTP synchronizes timekeeping among a set of distributed time servers and
clients. This synchronization allows events to be correlated when system logs
are created and other time-specific events occur.
NTP uses the User Datagram Protocol (UDP) as its transport protocol. All
NTP communication uses Coordinated Universal Time (UTC). An NTP network usually
receives its time from an authoritative time source, such as a radio clock or
an atomic clock attached to a time server. NTP distributes this time across the
network. NTP is extremely efficient; no more than one packet per minute is
necessary to synchronize two machines to within a millisecond of each other.
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 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 avoids synchronizing to a machine whose time may not be accurate, in
two ways. First, NTP never synchronizes to a machine that is not synchronized
itself. Second, NTP compares the time reported by several machines and does not
synchronize to a machine whose time is significantly different than the others,
even if its stratum is lower. This strategy effectively builds a
self-organizing tree of NTP servers.
The Cisco implementation of NTP does not support stratum 1 service; in
other words, it is not possible to connect to a radio or atomic clock (for some
specific platforms, however, you can connect a GPS time-source device). We
recommend that time service for your network be derived from the public NTP
servers available in the IP Internet.
If the network is isolated from the Internet, the Cisco implementation
of NTP allows a machine to be configured so that it acts as though it is
synchronized via NTP, when in fact it has determined the time using other
means. Other machines can then synchronize to that machine via NTP.
Several manufacturers include NTP software for their host systems,
and a publicly available version for systems running UNIX and its various
derivatives is also available. 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 routers.
The communications 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 by exchanging NTP messages between each pair of machines with an
The Cisco implementation of NTP supports three ways that a networking
device can obtain NTP time information on a network:
In a LAN environment, NTP can be configured to use IP broadcast or multicast
messages. As compared to polling, IP broadcast or multicast
messages reduce configuration complexity, because each machine can
simply be configured to send or receive broadcast or multicast messages.
However, the accuracy of timekeeping is marginally reduced because the
information flow is one-way only.
An NTP broadcast client listens for broadcast messages sent by an NTP
broadcast server at a designated IPv4 address. The client synchronizes the
local clock using the first received broadcast message.
An NTP multicast server periodically
sends a message to a designated IPv4 or IPv6 local multicast group address. An
NTP multicast client listens on this address for NTP messages.
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 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.