The local clock of
an S5500-EI Ethernet switch cannot be set as a reference clock. It can serve as
a reference clock source to synchronize the clock of other devices only after it
is synchronized.
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 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 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
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.
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. Switch A and Switch 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 Switch
A and Switch B, the clock of Switch A is set to 10:00:00 am while that of Switch
B is set to 11:00:00 am.
l
Switch B is used as the NTP time server, namely Switch
A synchronizes its clock to that of Switch B.
l
It takes 1 second for an NTP message to travel
from one switch to the other.

Figure 1-1
Basic work flow of NTP
The process of system clock synchronization
is as follows:
l
Switch A sends Switch B an NTP message, which is
timestamped when it leaves Switch A. The time stamp is 10:00:00 am (T1).
l
When this NTP message arrives at Switch B, it is
timestamped by Switch B. The timestamp is 11:00:01 am (T2).
l
When the NTP message leaves Switch B, Switch B
timestamps it. The timestamp is 11:00:02 am (T3).
l
When Switch A receives the NTP message, the
local time of Switch A is 10:00:03 am (T4).
Up to now, Switch 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 Switch A and Switch B:
Offset = ((T2-T1) + (T3-T4))/2 = 1
hour.
Based on these parameters, Switch A can
synchronize its own clock to the clock of Switch 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.
Switches running NTP can implement clock
synchronization in one of the following modes:
I. Server/client mode

Figure
1-3 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

Figure
1-4 Symmetric peers mode
A switch working in the symmetric active
mode periodically sends clock synchronization messages, with the Mode field in
the message set to 1 (symmetric active); the switch 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 switches. Then, the two
switches can synchronize, or be synchronized by, each other. If the clocks of
both switches have been already synchronized, the switch whose local clock has
a lower stratum level will synchronize the clock of the other switch.
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, 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

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, 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 symmetric peers
mode, broadcast mode and multicast mode, the client (or the symmetric active
peer) and the server (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.
1.2 NTP Configuration Task list
Complete the
following tasks to configure NTP:
Switches 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 switch 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 switches
working in the server/client 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 switch
|
ntp-service unicast-server { ip-address | server-name }
[ authentication-keyid keyid | priority | source-interface
interface-type interface-number | version number ]
*
|
Required
No NTP server is specified by default.
|
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 switch can act as a server to synchronize the
clock of other switches 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 switches 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 switch:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter
system view
|
system-view
|
—
|
|
Specify a
symmetric-passive peer for the switch
|
ntp-service unicast-peer { ip-address | peer-name } [ authentication-keyid
keyid | priority | source-interface interface-type
interface-number | version number ] *
|
Required
No
symmetric-passive peer is specified by default.
|
l
In the symmetric mode, you should use 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 switch working in NTP broadcast mode sends a reply and
synchronizes its local clock.
For switches 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 NTP broadcast mode can be configured only in the
specific interface view.
I. Configuring a 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 switch to work in the NTP broadcast client mode
|
ntp-service broadcast-client
|
Required
|
II. Configuring the 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 switch 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.
For switches working in the multicast mode,
you need to configure both the server and clients. The NTP multicast mode must
be configured in the specific interface view.
I. Configuring a 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 switch to work in the NTP
multicast client mode
|
ntp-service multicast-client [ ip-address ]
|
Required
|
II. Configuring the 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 switch to work in the NTP
multicast server mode
|
ntp-service multicast-server [ ip-address ] [ authentication-keyid
keyid | ttl ttl-number | version number ] *
|
Required
|
l
A multicast server can synchronize broadcast
clients only after its clock has been synchronized.
l
You can configure up to 1024 multicast clients,
among which 128 can take effect at the same time.
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.
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 an interface in the ntp-service unicast-server or ntp-service
unicast-peer command, this interface will be used for sending 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
|
|
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.5 Configuring Access-Control Rights
With the following command, you can
configure the NTP service access-control right to the local switch. There are
four access-control rights, as follows:
l
query: control
query permitted. This level of right permits the peer switch to perform control
query to the NTP service on the local switch but does not permit the peer switch
to synchronize its clock to the local switch. 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 switch to synchronize
its clock to the local switch but does not permit the peer switch to perform
control query.
l
server: server
access and query permitted. This level of right permits the peer switch to
perform synchronization and control query to the local switch but does not
permit the local switch to synchronize its clock to the peer switch.
l
peer: full
access. This level of right permits the peer switch to perform synchronization
and control query to the local switch and also permits the local switch to
synchronize its clock to the peer switch.
From the highest NTP service access-control
right to the lowest one are peer, server, synchronization,
and query. When a switch 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 switch, you need to create and configure an
ACL associated with the access-control right. For the configuration of ACL,
refer to the ACL part of the manual.
Follow these steps to configure the NTP
service access-control right to the local switch:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Configure the NTP service access-control
right to the local switch
|
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 switch 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
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. Otherwise,
the NTP authentication function cannot be normally enabled.
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 peer mode) with the corresponding
NTP server (symmetric-passive peer if in the symmetric peer mode). Otherwise,
the NTP authentication feature cannot be normally enabled.
l
For the broadcast server mode or multicast
server mode, you need to associate the specified authentication key on the
broadcast server or multicast server with the corresponding NTP server. Otherwise,
the NTP authentication feature cannot be normally enabled.
l
For 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, 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
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
You can associate a non-existing key with
an NTP server. To enable NTP authentication, you must configure the key and
specify it as a trusted key after associating the key with the NTP server.
|
|
Symmetric peers mode:
ntp-service unicast-peer { ip-address | peer-name } authentication-keyid
keyid
|
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.
II. Configuring NTP authentication
for a server
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
|
Required
You can associate a non-existing key with
an NTP server. To enable NTP authentication, you must configure the key and
specify it as a trusted key after associating the key with the NTP server.
|
|
Multicast server mode:
ntp-service multicast-server authentication-keyid keyid
|