When configuring NTP, go to these sections for information you are
interested in:
l
NTP Overview
l
NTP Configuration Task List
l
Configuring the Operation
Modes of NTP
l
Configuring the Local Clock
as a Reference Source
l
Configuring Optional Parameters
of NTP
l
Configuring Access-Control
Rights
l
Configuring NTP Authentication
l
Displaying and Maintaining
NTP
l
NTP Configuration Examples
The term router and the router icons used in this chapter refer to
the routers in a generic sense and the switches running routing protocols.
1.1 NTP Overview
Defined in
RFC 1305, the network time protocol (NTP) synchronizes timekeeping among
distributed time servers and clients. NTP runs over the user datagram protocol
(UDP), using UDP port 123.
The purpose
of using NTP is to keep consistent timekeeping among all clock-dependent
devices within the network so that the devices can provide diverse applications
based on the consistent time.
For a local system running NTP, its time can be synchronized by
other reference sources and can be used as a reference source to synchronize
other clocks.
An
administrator can by no means keep time synchronized among all the devices
within a network by changing the system clock on each station, because this is
a huge amount of workload and cannot guarantee the clock precision. NTP,
however, allows quick clock synchronization within the entire network while it
ensures a high clock precision.
NTP is used
when all devices within the network must be consistent in timekeeping, for
example:
l
In analysis of the log information and debugging
information collected from different devices in network management, time must
be used as reference basis.
l
All devices must use the same reference clock in
a charging system.
l
To implement certain functions, such as
scheduled restart of all devices within the network, all devices must be
consistent in timekeeping.
l
When multiple systems process a complex event in
cooperation, these systems must use that same reference clock to ensure the
correct execution sequence.
l
For increment backup between a backup server and
clients, timekeeping must be synchronized between the backup server and all the
clients.
Advantages
of NTP:
l
NTP uses a stratum to describe the clock
precision, and is able to synchronize time among all devices within the network.
l
NTP supports access control and MD5
authentication.
l
NTP can unicast, multicast or broadcast protocol
messages.
Figure 1-1 shows the basic work flow of NTP. Device A and Device B are
interconnected over a network. They have their own independent system clocks,
which need to be automatically synchronized through NTP. For an easy
understanding, we assume that:
l
Prior to system clock synchronization between
Device A and Device B, the clock of Device A is set to 10:00:00am while that of
Device B is set to 11:00:00am.
l
Device B is used as the NTP time server, namely,
the clock of Device A is synchronized by that of Device B.
l
It takes 1 second for an NTP message to travel
from one device to the other.

Figure 1-1 Basic work flow of NTP
The process of system clock synchronization
is as follows:
l
Device A sends Device B an NTP message, which is
timestamped when it leaves Device A. The time stamp is 10:00:00am (T1).
l
When this NTP message arrives at Device B, it is
timestamped by Device B. The timestamp is 11:00:01am (T2).
l
When the NTP message leaves Device B, Device B
timestamps it. The timestamp is 11:00:02am (T3).
l
When Device A receives the NTP message, the
local time of Device A is 10:00:03am (T4).
Up to now, Device A has sufficient
information to calculate the following two important parameters:
l
The roundtrip delay of NTP message: Delay = (T4–T1)
– (T3-T2) = 2 seconds.
l
Time difference between Device A and Device B:
Offset = ((T2-T1) + (T3-T4))/2 = 1
hour.
Based on these parameters, Device A can
synchronize its own clock to the clock of Device B.
This is only a rough description of the work mechanism of NTP. For
details, refer to RFC 1305.
NTP uses two
types of messages, clock synchronization message and NTP control message. An
NTP control message is used in environments where network management is needed.
As it is not a must for clock synchronization, it will not be discussed in this
document.
All NTP messages mentioned in this document refer to NTP clock
synchronization messages.
A clock
synchronization message is encapsulated in a UDP message, in the format shown
in Figure 1-2.

Figure 1-2 Clock synchronization message format
Main fields
are described as follows:
l
LI: 2-bit leap indicator. When set to 11, it
warns of an alarm condition (clock unsynchronized); when set to any other
value, it is not to be processed by NTP.
l
VN: 3-bit version number, indicating the version
of NTP. The latest version is version 3.
l
Mode: a 3-bit code indicating the work mode of
NTP. This field can be set to these values: 0 – reserved; 1 –
symmetric active; 2 – symmetric passive; 3 – client; 4 –
server; 5 – broadcast or multicast; 6 – NTP control message; 7
– reserved for private use.
l
Stratum: an 8-bit integer indicating the stratum
level of the local clock, with the value ranging from 1 to 16. The clock
precision decreases from stratum 1 through stratum 16. A stratum 1 clock has
the highest precision, and a stratum 16 clock is not synchronized and cannot be
used as a reference clock.
l
Poll: 8-bit signed integer indicating the poll
interval, namely the maximum interval between successive messages.
l
Precision: an 8-bit signed integer indicating
the precision of the local clock.
l
Root Delay: roundtrip delay to the primary
reference source.
l
Root Dispersion: the maximum error of the local
clock relative to the primary reference source.
l
Reference Identifier: Identifier of the
particular reference source.
l
Reference Timestamp: the local time at which the
local clock was last set or corrected.
l
Originate Timestamp: the local time at which the
request departed the client for the service host.
l
Receive Timestamp: the local time at which the
request arrived at the service host.
l
Transmit Timestamp: the local time at which the
reply departed the service host for the client.
l
Authenticator: authentication information.
Devices
running NTP can implement clock synchronization in one of the following modes:
l
Client/server mode
l
Symmetric peers mode
l
Broadcast mode
l
Multicast mode
You can
select operation modes of NTP as needed. In case that the IP address of the NTP
server or peer is unknown and many devices in the network need to be
synchronized, you can adopt the broadcast or multicast mode; while in the
client/server and symmetric peers modes, a device is synchronized from the
specified server or peer, and thus clock reliability is enhanced.
I. Client/server mode

Figure
1-3 Client/server mode
In client/server
mode, a client can be synchronized to a server, but not vice versa. When
working in the client/server mode, a client sends a clock synchronization
message to servers, with the Mode field in the message set to 3 (client mode).
Upon receiving the message, the servers automatically work in the server mode
and send a reply, with the Mode field in the messages set to 4 (server mode).
Upon receiving the replies from the servers, the client performs clock
filtering and selection, and its local clock is synchronized to that of the
optimal reference source.
II. Symmetric peers mode

Figure
1-4 Symmetric peers mode
After the
symmetric peers mode is configured, the symmetric active peer sends clock
synchronization messages with the Mode field set to 3 (client mode) to the
symmetric passive peer. The device that receives the message automatically
enters the symmetric passive mode and sends a reply, with the Mode field in the
message set to 4 (server mode). By exchanging messages, the symmetric peers
mode is established between the two devices. Then, the two devices can
synchronize, or be synchronized by, each other. In this case, the Mode field is
set to 1 (symmetric active peer) in the clock synchronization messages sent by
the symmetric active peer, and that is set to 2 (symmetric passive peer) in the
response messages sent by the symmetric passive peer. If both devices have reference
clocks, the device whose local clock has a lower stratum level will synchronize
the clock of the other device.
III. Broadcast mode

Figure
1-5 Broadcast mode
In the
broadcast mode, a server periodically sends clock synchronization messages to
the broadcast address 255.255.255.255. Clients listen to the broadcast messages
from servers. After a client receives the first broadcast message, the client
initiates the client/server mode request to acquire the network delay between
the client and the server. Then, the client enters the broadcast client mode
and continues listening to broadcast messages, and synchronizes its local clock
based on the received broadcast messages.
IV. Multicast mode

Figure
1-6 Multicast mode
In the
multicast mode, a server periodically sends clock synchronization messages to
the user-configured multicast address, or, if no multicast address is
configured, to the default NTP multicast address 224.0.1.1. Clients listen to
the multicast messages from servers. After a client receives the first
multicast message, the client initiates the client/server mode request to
acquire the network delay between the client and the server. Then, the client
enters the multicast client mode and continues listening to multicast messages,
and synchronizes its local clock based on the received multicast messages.
In symmetric peers mode, broadcast mode and multicast mode, the
client (or the symmetric active peer) and the server (or the symmetric passive
peer) can work in the specified NTP working mode only after they exchange NTP
messages with the Mode field being 3 (client mode) and the Mode field being 4
(server mode). During this message exchange process, NTP clock synchronization
can be implemented.
The client/server
mode and symmetric mode support multiple instances of NTP and thus support
clock synchronization within an MPLS VPN network. Namely, network devices (CEs
and PEs) at different physical location can get their clocks synchronized
through MPLS VPN connection, as long as they are in the same VPN. The specific
functions are as follows:
l
The NTP client on a customer edge device (CE)
can be synchronized to the NTP server on another CE.
l
The NTP client on a CE can be synchronized to
the NTP server on a provider edge device (PE).
l
The NTP client on a PE can be synchronized to
the NTP server on a CE through a designated VPN instance.
l
The NTP server on a PE can synchronize multiple NTP
clients on different CEs.
l
A CE is a device that has an interface directly
connecting to the service provider (SP). A CE is not
“aware of” the presence of the
VPN.
l
A PE is a device that directly connecting to
CEs. In an MPLS network, all events related to VPN
processing occur on the PE.
1.2 NTP Configuration Task List
Complete
these tasks to configure NTP:
According to
the devices’ position in the network and the network structure, devices can
implement clock synchronization in one of the following modes:
l
Client/server mode
l
Symmetric peers mode
l
Broadcast mode
l
Multicast mode
For the client/server
mode or symmetric peers mode, you need to configure only clients or
symmetric-active peers; for the broadcast or multicast mode, you need to
configure both servers and clients.
A single device can have a maximum of 128 associations at the same
time, including static associations and dynamic associations.
l
A static association refers to an association
that a user has manually created by using an NTP command;
l
A dynamic association is a temporary association
created by the system during operation. A dynamic association will be removed
if the system fails to receive messages from it over a specific long time.
In the client/server mode, for example, when you carry out a command
to synchronize the time to a server, the system will create a static association,
and the server will just respond passively upon the receipt of a message,
rather than creating an association (static or dynamic). In the symmetric mode,
static associations will be created at the symmetric-active peer side, and
dynamic associations will be created at the symmetric-passive peer side; In the
broadcast or multicast mode, static associations will be created at the server
side, and dynamic associations will be created at the client side.
For devices
working in the client/server mode, you only need to make configurations on the
clients, and not on the servers.
Follow these
steps to configure an NTP client:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Specify an
NTP server for the device
|
ntp-service unicast-server [ vpn-instance vpn-instance-name
] { ip-address | server-name } [ authentication-keyid
keyid | priority | source-interface interface-type
interface-number | version number ] *
|
Required
By
default, no NTP server is specified for the device.
|
l
In the ntp-service unicast-server
command, ip-address must be a host address, rather than a
broadcast address, a multicast address or the IP address of the local clock.
l
When the interface
sending the NTP packet is specified by the source-interface argument,
the source IP address of the NTP packet will be configured as the primary IP
address of the specified interface.
l
A device can act as a server to synchronize the
clock of other devices only after its clock has been synchronized. If the clock of a server has a stratum level higher than or
equal to that of a client’s clock, the client will not synchronize its
clock to the server’s.
l
You can configure
multiple servers by repeating the ntp-service unicast-server command. The clients will choose the
optimal reference source.
For devices
working in the symmetric mode, you need to specify a symmetric-passive on a symmetric-active
peer.
Following
these steps to configure a symmetric-active device:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Specify a
symmetric-passive peer for the device
|
ntp-service unicast-peer [ vpn-instance vpn-instance-name
] { ip-address | peer-name } [ authentication-keyid keyid
| priority | source-interface interface-type
interface-number | version number ] *
|
Required
By
default, no symmetric-passive peer is specified for the device.
|
l
In the symmetric mode, you should use the ntp-service
refclock-master command or any NTP configuration command in Configuring the Operation Modes of NTP
to enable NTP; otherwise, a symmetric-passive peer will not process NTP packets
from a symmetric-active peer.
l
In the ntp-service unicast-peer
command, ip-address must be a host address, rather than a broadcast
address, a multicast address or the IP address of the local clock.
l
When the interface
used to send NTP messages is specified by the source-interface argument,
the source IP address of the NTP message will be configured as the primary IP
address of the specified interface.
l
Typically, at least one of the symmetric-active
and symmetric-passive peers has been synchronized; otherwise the clock
synchronization will not proceed.
l
You can configure multiple symmetric-passive
peers by repeating the ntp-service unicast-peer command.
The
broadcast server periodically sends NTP broadcast messages to the broadcast
address 255.255.255.255. After receiving the messages, the device working in
NTP broadcast mode sends a reply and synchronizes its local clock.
For devices
working in the broadcast mode, you need to configure both the server and
clients. Because an interface need to be specified on the broadcast server for
sending NTP broadcast messages and an interface also needs to be specified on
each broadcast client for receiving broadcast messages, the commands for NTP
broadcast mode can be configured only in the specific interface view.
I. Configuring a broadcast client
Follow these
steps to configure an NTP broadcast client:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Enter
interface view
|
interface interface-type interface-number
|
Required
Enter the
interface used to receive NTP broadcast messages
|
|
Configure
the device to work in the NTP broadcast client mode
|
ntp-service broadcast-client
|
Required
|
II. Configuring the broadcast
server
Follow these
steps to configure the NTP broadcast server:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Enter
interface view
|
interface interface-type interface-number
|
Required
Enter the
interface used to send NTP broadcast messages
|
|
Configure
the device to work in the NTP broadcast server mode
|
ntp-service broadcast-server [ authentication-keyid keyid
| version number ] *
|
Required
|
The
multicast server periodically sends NTP multicast messages to multicast clients,
which send replies after receiving the messages and synchronize their local
clocks.
If using the
multicast mode, you need to configure both the server and clients. The commands
for the NTP multicast mode must be configured in the specific interface view.
You can configure a maximum of 1,024 multicast clients, among which 128 can
take effect at the same time.
I. Configuring a multicast client
Follow these
steps to configure an NTP multicast client:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Enter
interface view
|
interface interface-type interface-number
|
Required
Enter the
interface used to receive NTP multicast messages
|
|
Configure
the device to work in the NTP multicast client mode
|
ntp-service multicast-client [ ip-address ]
|
Required
The
multicast IP address must be 224.0.1.1.
|
II. Configuring the multicast
server
Follow these
steps to configure the NTP multicast server:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Enter
interface view
|
interface interface-type interface-number
|
Required
Enter the
interface used to send NTP multicast message
|
|
Configure
the device to work in the NTP multicast server mode
|
ntp-service multicast-server [ ip-address ] [ authentication-keyid
keyid | ttl ttl-number | version number ] *
|
Required
|
A multicast server can synchronize broadcast clients only after its
clock has been synchronized.
1.4 Configuring the Local Clock as a
Reference Source
A network
device can get its clock synchronized in one of the following two ways:
l
Synchronized to the local clock, which as the
reference source.
l
Synchronized to another device on the network in
any of the four NTP operation modes previously described.
If you
configure two synchronization modes, the device will choose the optimal clock
as the reference source.
Follow these
steps to configure the local clock as a reference source:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Configure
the local clock as a reference source
|
ntp-service
refclock-master [ ip-address ] [ stratum
]
|
Required
|
In this command, ip-address must be 127.127.1.u, where u
ranges from 0 to 3, representing the NTP process ID.
1.5 Configuring Optional Parameters of NTP
If you specify the interface used to send an NTP message, the device
sets the source IP address of the NTP message as the primary IP address of the
specified interface when sending the NTP message.
When the device responds to an NTP request received, the source IP
address of the NTP response is always the IP address of the interface that
received the NTP request.
Following
these steps to configure the local interface used to send NTP messages:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Configure
the interface used to send NTP messages
|
ntp-service
source-interface interface-type
interface-number
|
Required
|
Caution:
l
If you have specified an interface in the ntp-service
unicast-server or ntp-service unicast-peer command, this interface
will be used for sending NTP messages.
l
If you have configured the ntp-service broadcast-server
or ntp-service multicast-server command, the interface used to
broadcast or multicast NTP messages is the interface configured with the
respective command.
Follow these steps to disable an interface
from receiving NTP messages:
|
To do…
|
Use the
command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter interface view
|
interface interface-type
interface-number
|
Required
|
|
Disable the interface from receiving NTP
messages
|
ntp-service in-interface disable
|
Required
An interface is enabled to receive NTP
messages by default.
|
Follow these steps to configure the maximum
number of dynamic sessions allowed to be established locally:
|
To do…
|
Use the
command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure the maximum number of dynamic
sessions allowed to be established locally
|
ntp-service max-dynamic-sessions number
|
Required
100 by default
|
1.6 Configuring Access-Control Rights
With the following command, you can
configure the NTP service access-control right to the local device. There are
four access-control rights, as follows: