When configuring NTP,
go to these sections for information you are interested in:
l
NTP Overview
l
Configuring the Operation
Modes of NTP
l
Configuring Optional Parameters
of NTP
l
Configuring Access-Control
Rights
l
Configuring NTP Authentication
l
Displaying and Maintaining
NTP
l
NTP Configuration Examples
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 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 consistent time.
For a local system running NTP, its time
can be synchronized with a reference source; it can also be used as a reference
source to synchronize other device's clock.
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
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.
l
All devices must use the same reference clock in
a charging system.
An administrator can by no means keep
synchronized time 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.
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 1 and Device 2 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 1 and Device 2, the clock of Device 1 is set to 10:00:00am while that of
Device 2 is set to 11:00:00am.
l
Device 2 is used the NTP time server, namely
Device 1 synchronizes its clock to that of Device 2.
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 1 sends Device 2 an NTP message, which is
timestamped when it leaves Device 1. The time stamp is 10:00:00am (T1).
l
When this NTP message arrives at Device 2, it is
timestamped by Device 2. The timestamp is 11:00:01am (T2).
l
When the NTP message leaves Device 2, Device 2
timestamps it. The timestamp is 11:00:02am (T3).
l
When Device 1 receives the NTP message, the
local time of Device 1 is 10:00:03am (T4).
Up to now, Device 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 1 and Device 2:
Offset = ((T2-T1) + (T3-T4))/2 = 1
hour.
Based on these parameters, Device 1 can
synchronize its own clock to the clock of Device 2.
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 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 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.
l
A device in the network can implement time
synchronization in two modes: it can be synchronized to the local clock or with
another device in the network. S5500-SI series support the time synchronization with another device in the network
in any of the NTP operation modes.
l
H3C S5500-SI series Ethernet switches can be
configured with the NTP broadcast server mode or NTP multicast server mode only
after clock synchronization is implemented on them.
Devices running NTP can implement clock
synchronization in one of the following modes:
I. Server/client mode
When working in the server/client 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 synchronizes
its local clock to that of the optimal reference source.
In this mode, a client can be synchronized
to a server, but not vice versa.
II. Symmetric peers mode
A device working in the symmetric active
mode periodically sends clock synchronization messages, with the Mode field in
the message set to 1 (symmetric active); the device that receives this message
automatically enters the symmetric passive mode and sends a reply, with the
Mode field in the message set to 2 (symmetric passive). 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. If the clocks of
both devices have been already synchronized, the device whose local clock has a
lower stratum level will synchronize the clock of the other device.
III. Broadcast mode
In the broadcast mode, a server
periodically sends clock synchronization messages to the broadcast address
255.255.255.255, with the Mode field in the messages set to 5 (broadcast mode).
Clients listen to the broadcast messages from servers. After a client receives
the first broadcast message, the client and the server start to exchange
messages, with the Mode field set to 3 (client mode) and 4 (server mode) to
calculate the network delay between 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
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, with the Mode field in the messages set to 5 (multicast mode).
Clients listen to the multicast messages from servers. After a client receives
the first multicast message, the client and the server start to exchange
messages, with the Mode field set to 3 (client mode) and 4 (server mode) to
calculate the network delay between 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 the peer,
broadcast, or multicast mode, the client (or symmetric-active peer) and the
server (or symmetric-passive peer) can enter the specified NTP operation mode
only after the NTP messages whose Mode field is 3 (in client mode) or 4 (in
server mode) are exchanged between them. Clock synchronization can be achieved
through this message exchange.
Table 1-1 For NTP configuration tasks,
go to these sections
1.3 Configuring the Operation Modes of NTP
Devices can implement clock synchronization
in one of the following modes:
l
Server/client mode
l
Symmetric mode
l
Broadcast mode
l
Multicast mode
For the server/client mode or symmetric
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. A static association refers to an
association that a user has manually created by using an NTP command, while 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 server/client 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 server/client
mode, you only need to make configurations on the clients, and not on the
servers.
Table 1-2 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 { ip-address | server-name }
[ authentication-keyid keyid | priority | source-interface
interface-type interface-number | version number ]
*
|
Required
|
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
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 only need to make configurations on the symmetric-active device, and not on
symmetric-passive devices.
Table 1-3 Following these steps to
configure a symmetric-active device
|
To do...
|
Use the command...
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Specify an symmetric-passive peer for the
device
|
ntp-service unicast-peer { ip-address | peer-name } [ authentication-keyid
keyid | priority | source-interface interface-type
interface-number | version number ] *
|
Required
|
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
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.
For devices working in the broadcast mode,
you need to configure both the server and clients. The broadcast server
periodically sends NTP broadcast messages to the broadcast address 255.255.255.255.
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 NTP broadcast mode can
be configured only in the specific interface view.
I. Configuring a broadcast client
Table 1-4 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
Table 1-5 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
|
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
|
For devices working in the multicast mode,
you need to configure both the server and clients. The multicast server
periodically sends NTP multicast messages to multicast clients. 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
Table 1-6 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
|
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
|
II. Configuring the multicast
server
Table 1-7 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
|
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 Optional Parameters of NTP
After you specify the interface used to
send NTP messages, the source IP address of the NTP message will be configured
as the primary IP address of the specified interface.
Table 1-8 Following these steps to
configure the 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:
If you have
specified a sending interface by using the ntp-service unicast-server or
ntp-service unicast-peer command, the IP address of the specified
interface will be used as the source IP address of outgoing NTP messages.
Table 1-9 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
|
—
|
|
Disable the interface from receiving NTP
messages
|
ntp-service in-interface disable
|
Required
An interface is enabled to receive NTP
messages by default
|
Table 1-10 Follow these steps to
configure the allowable maximum number of dynamic sessions
|
To do...
|
Use the command...
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure the allowable maximum number of
dynamic sessions
|
ntp-service max-dynamic-sessions number
|
Required
100 by default
|
1.5 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:
l
query: control
query permitted. This level of right permits the peer device to perform control
query to the NTP service on the local device but does not permit the peer
device to synchronize its clock to the local device. The so-called
“control query” refers to query of some states of the NTP service,
including alarm information, authentication status, clock source information,
and so on.
l
synchronization:
server access only. This level of right permits the peer device to synchronize
its clock to the local device but does not permit the peer device to perform
control query.
l
server: server
access and query permitted. This level of right permits the peer device to
perform synchronization and control query to the local device but does not
permit the local device to synchronize its clock to the peer device.
l
peer: full
access. This level of right permits the peer device to perform synchronization
and control query to the local device and also permits the local device to
synchronize its clock to the peer device.
From the highest NTP service access-control
right to the lowest one are peer, server, synchronization,
and query. When a device receives an NTP request, it will perform an
access-control right match and will use the first matched right.
Prior to configuring the NTP service
access-control right to the local device, you need to create and configure an
ACL associated with the access-control right.
Table 1-11 Follow these steps to
configure the NTP service access-control right to the local device
|
To do...
|
Use the command...
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure the NTP service access-control
right to the local device
|
ntp-service access { peer | query | server | synchronization
} acl-number
|
Required
peer by
default
|
1.6 Configuring NTP Authentication
The NTP authentication feature should be enabled for a system running
NTP in a network where there is a high security demand. This feature enhances
the network security by means of client-server key authentication, which
prohibits a client from synchronizing with a device that has failed
authentication.
The configuration NTP authentication
involves configuration tasks to be implemented on the client and on the server.
When configuring the NTP authentication
feature, pay attention to the following principles:
l
In the server/client mode, if the NTP
authentication feature has not been enabled for the client, the client can
synchronize with the server regardless the NTP authentication feature has been
enabled for the server or not.
l
For all synchronization modes, when you enable
the NTP authentication feature, you should configure an authentication key and
specify it as a trusted key. Namely, the ntp-service authentication enable
command must work together with the ntp-service authentication-keyid
command and the ntp-service reliable authentication-keyid command.
l
For all synchronization modes, the server side
and the client side must be consistently configured.
l
If the NTP authentication is enabled on a
client, the client can be synchronized only to a server that can provide a
trusted authentication key.
I. Configuring NTP authentication
for a client
Table 1-12 Follow these steps to
configure NTP authentication for a client
|
To do...
|
Use the command...
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable NTP authentication
|
ntp-service authentication enable
|
Required
Disabled by default
|
|
Configure an NTP authentication key
|
ntp-service authentication-keyid keyid authentication-mode md5 value
|
Required
No NTP authentication key by default
|
|
Configure the key as a trusted key
|
ntp-service reliable authentication-keyid
keyid
|
Required
No authentication key is configured to be
trusted by default
|
|
Associate the specified key with an NTP
server
|
Server/client mode:
ntp-service unicast-server { ip-address | server-name } authentication-keyid
keyid
|
Required
|
|
Symmetric peers mode:
ntp-service unicast-peer { ip-address | peer-name } authentication-keyid
keyid
|
l
After you enable the NTP authentication feature
for the client, make sure that you configure for the client an authentication
key that is the same as on the server and specify that the authentication is
trusted; otherwise, the client cannot be synchronized to the server.
l
For the server/client mode or symmetric mode,
you need to associate the specified authentication key on the client
(symmetric-active peer if in the symmetric peers mode) with the corresponding
NTP server (symmetric-passive peer if in the symmetric peers mode). In these
two modes, multiple servers may have been specified on a client, so the
authentication key will be used to determine the server to which the client is
to be synchronized.
l
For the broadcast server mode or multicast
server mode, you need to associate the specified authentication key on the
broadcast or multicast server with the server itself.
II. Configuring NTP authentication
for a server
Table 1-13 Follow these steps to
configure NTP authentication for a server
|
To do...
|
Use the command...
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable NTP authentication
|
ntp-service authentication enable
|
Required
Disabled by default
|
|
Configure an NTP authentication key
|
ntp-service authentication-keyid keyid authentication-mode md5 value
|
Required
No NTP authentication key by default
|
|
Configure the key as a trusted key
|
ntp-service reliable authentication-keyid
keyid
|
Required
No authentication key is configured to be
trusted by default
|
|
Enter interface view
|
interface interface-type
interface-number
|
—
|
|
Associate the specified key with an NTP
server
|
Broadcast server mode:
ntp-service broadcast-server [ authentication-keyid keyid
| version number ] *
|
Required
|
|
Multicast server mode:
ntp-service multicast-server [ ip-address ] [ authentication-keyid
keyid | ttl ttl-number | version number ]
*
|
The procedure of
configuring NTP authentication on a server is the same as that on a client, and
the same authentication key must be configured on both the server and client
sides.
1.7 Displaying and Maintaining NTP
Table 1-14 Displaying and maintaining
NTP
|
To do...
|
Use the command...
|
Remarks
|
|
Display the information of NTP service
status
|
display ntp-service status
|
Available in any view
|
|
Display the information of NTP sessions
|
display ntp-service sessions [ verbose ]
|
|
Display the brief information of the NTP
servers from the local device back to the primary reference source
|
display ntp-service trace
|
1.8 NTP Configuration Examples
