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 association.
The Cisco
implementation of NTP supports three ways that a networking device can obtain
NTP time information on a network:
-
By polling host servers
-
By listening to NTP broadcasts
-
By listening to NTP multicasts
-
By using a peer-to-peer relationship.
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.
Preventing Issues due to GPS Week Number Rollover (WNRO)
-
If there are no GPS sources in the NTP source chain or server chain, there is no impact of GPS Week Number Rollover (WNRO).
-
GPS WNRO affects only the system clock and not user traffic.
-
Contact your GPS manufacturer to fix the GPS source for this condition.
To mitigate impact of GPS sources that are subject to GPS WNRO perform the following optional workarounds:
-
If the GPS source has been identified to be a cause of potential disruption on April 6, 2019 (or after), configure ntp master
in the Cisco that is device connected to this source, and its clock on the Stratum 1 device to preventively isolate it. This
configuration enables the device to present its own clock for synchronization to downstream NTP clients.
Note
|
The usage of ntp master command as mentioned above is only a workaround to this condition. Use this command until the GPS
source-related conditions are resolved, and to prevent the distribution of incorrect clock values throughout the network.
|
-
Configure multiple NTP servers (ideally 4, but more than 3) at Stratum 2 level of the network, to enable NTP clients at Stratum
2 level to get clock from more than one Stratum 1 server. This way, WNRO affected Stratum 1 servers are staged to be marked
as ‘false ticker’ or ‘outlier’ clock sources as compared to other non-WNRO affected Stratum 1 servers.
Note
|
To configure day light saving time (DST) on your IOS XR 64-bit device, select the appropriate country and city. The device
will automatically update the DST based on the internal mappings at kernel level. The DST keyword is not available in the configuration CLI, since manual configuration of DST is not supported on IOS XR 64-bit devices.
|