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.

1.1.1 Applications of NTP

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.

1.1.2 How NTP Works

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 (T₁).

l When this NTP message arrives at Device 2, it is timestamped by Device 2. The timestamp is 11:00:01am (T₂).

l When the NTP message leaves Device 2, Device 2 timestamps it. The timestamp is 11:00:02am (T₃).

l When Device 1 receives the NTP message, the local time of Device 1 is 10:00:03am (T₄).

Up to now, Device has sufficient information to calculate the following two important parameters:

l The roundtrip delay of NTP message: Delay = (T₄–T₁) – (T₃-T₂) = 2 seconds.

l Time difference between Device 1 and Device 2: Offset = ((T₂-T₁) + (T₃-T₄))/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.

1.1.3 NTP Message Format

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.

& Note:

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.

1.1.4 Operation Modes of NTP

& Note:

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.

& Note:

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.

1.2 NTP Configuration Tasks

Table 1-1 For NTP configuration tasks, go to these sections

To do…	Remarks	Related section
Configure the operation modes of NTP	Required	See section 1.3 "Configuring the Operation Modes of NTP".
Configure optional parameters of NTP	Optional	See section 1.4 Configuring Optional Parameters of NTP".
Configure access-control rights	Optional	See section 1.5 "Configuring Access-Control Rights".
Configure NTP authentication	Optional	See section 1.6 Configuring NTP Authentication".

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.

& Note:

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.

1.3.1 Configuring NTP Server/Client Mode

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

& Note:

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.

1.3.2 Configuring the NTP Symmetric Mode

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

& Note:

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.

1.3.3 Configuring NTP Broadcast Mode

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

& Note:

A broadcast server can synchronize broadcast clients only after its clock has been synchronized.

1.3.4 Configuring NTP Multicast Mode

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

& Note:

A multicast server can synchronize broadcast clients only after its clock has been synchronized.

1.4 Configuring Optional Parameters of NTP

1.4.1 Configuring the Interface to Send NTP Messages

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.

1.4.2 Disabling an Interface from Receiving 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

1.4.3 Configuring the Allowable Maximum Number of Dynamic Sessions

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

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.

1.5.1 Configuration Prerequisites

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.

1.5.2 Configuration Procedure

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

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

& Note:

The access-control right mechanism provides only a minimum degree of security protection for the system running NTP. A more secure method is identity authentication.

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.

1.6.1 Configuration Prerequisites

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.

1.6.2 Configuration Procedure

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
Associate the specified key with an NTP server	Symmetric peers mode: ntp-service unicast-peer { ip-address \| peer-name } authentication-keyid keyid	Required

& Note:

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
Associate the specified key with an NTP server	Multicast server mode: ntp-service multicast-server [ ip-address ] [ authentication-keyid keyid \| ttl ttl-number \| version number ] *	Required

& Note:

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

& Note:

For H3C S5500-SI series Ethernet switches, local clock cannot serve as NTP master clock.

1.8.1 Configuring NTP Server/Client Mode

I. Network requirements

The clock of Device 1 is synchronized, with a stratum level of 2. Device 1 is to be used as the NTP server of Device 2, with Device 2 as the client.

II. Network diagram

Figure 1-3 Network diagram for NTP server/client mode configuration

III. Configuration procedure

1) Configuration on Device 1:

The clock of Device 1 is synchronized, with a stratum level of 2.

2) Configuration on Device 2:

# Display the NTP status of Device 2 before clock synchronization.

<Device2> display ntp-service status

Clock status: unsynchronized

Clock stratum: 16

Reference clock ID: none

Nominal frequence: 100.0000 Hz

Actual frequence: 100.0000 Hz

Clock precision: 2^18

Clock offset: 0.0000 ms

Root delay: 0.00 ms

Root dispersion: 0.00 ms

Peer dispersion: 0.00 ms

Reference time: 00:00:00.000 UTC Jan 1 1900 (00000000.00000000)

# Specify Device 1 as the NTP server of Device 2 so that Device 2 is synchronized to Device 1.

<Device2> system-view

[Device2] ntp-service unicast-server 1.0.1.11

# Display the NTP status of Device 2 after clock synchronization.

[Device2] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 1.0.1.11

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: -3.4643 ms

Root delay: 8.60 ms

Root dispersion: 228.75 ms

Peer dispersion: 10.96 ms

Reference time: 10:12:25.314 UTC Sep 21 2006(C8BCE409.5068A936)

As shown above, Device 2 has been synchronized to Device 1, and the clock stratum level of Device 2 is 3, while that of Device 1 is 2.

# Display the NTP session information of Device 2, which shows that an association has been set up between Device 2 and Device 1.

[Device2] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[12345] 1.0.1.11 127.127.1.0 3 255 128 121 -3.5 8.6 3.6

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured Total associations : 1

1.8.2 Configuring the NTP Symmetric Mode

I. Network requirements

The clock of Device 3 is synchronized, with a stratum level of 2. Device 3 is to be used as the NTP server of Device 4, with Device 4 as the client. At the same time, Device 4 will act as peer of Device 5, Device 5 in the symmetric-active mode while Device 4 in the symmetric-passive mode.

II. Network diagram

Figure 1-4 Network diagram for NTP symmetric peers mode configuration

III. Configuration procedure

1) Configuration on Device 3:

The clock of Device 3 is synchronized, with a stratum level of 2.

2) Configuration on Device 4:

# Specify Device 3 as the NTP server of Device 4.

<Device4> system-view

[Device4] ntp-service unicast-server 3.0.1.31

3) Configuration on Device 5 (after Device 4 is synchronized to Device 3):

# Specify the local clock as the reference source, with the stratum level of 1.

# Configure Device 4 as a symmetric peer after local synchronization.

[Device5] ntp-service unicast-peer 3.0.1.32

In the step above, Device 4 and Device 5 are configured as symmetric peers, with Device 5 in the symmetric-active mode and Device 4 in the symmetric-passive mode. Because the stratus level of Device 5 is 1 while that of Device 4 is 3, Device 4 is synchronized to Device 5.

# Display the NTP status of Device 4 after clock synchronization.

[Device4] display ntp-service status

Clock status: synchronized

Clock stratum: 2

Reference clock ID: 3.0.1.33

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: -21.1982 ms

Root delay: 15.00 ms

Root dispersion: 775.15 ms

Peer dispersion: 34.29 ms

Reference time: 15:22:47.083 UTC Sep 19 2005 (C6D95647.153F7CED)

As shown above, Device 4 has been synchronized to Device 5, and the clock stratum level of Device 4 is 2, while that of Device 5 is 1.

# Display the NTP session information of Device 4, which shows that an association has been set up between Device 4 and Device 5.

[Device4] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[245] 3.0.1.31 127.127.1.0 2 15 64 24 10535.0 19.6 14.5

[12345] 3.0.1.33 LOCL 1 14 64 27 -77.0 16.0 14.8

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured Total associations : 2

1.8.3 Configuring NTP Broadcast Mode

I. Network requirements

The clock of Device 3 is synchronized, with a stratum level of 2, and Device 3 sends out broadcast messages from VLAN-interface2. Device 4 and Device 1 receive broadcast messages through their respective VLAN-interface2.

II. Network diagram

Figure 1-5 Network diagram for NTP broadcast mode configuration

III. Configuration procedure

1) Configuration on Device 3:

The clock of Device 3 is synchronized, with a stratum level of 2.

# Configure Device 3 to work in the broadcast server mode and send broadcast messages through VLAN-interface2.

[Device3] interface Vlan-interface 2

[Device3-Vlan-interface2] ntp-service broadcast-server

2) Configuration on Device 4:

# Configure Device 4 to work in the broadcast client mode and receive broadcast messages on VLAN-interface2.

<Device4> system-view

[Device4] interface Vlan-interface 2

[Device4-Vlan-interface2] ntp-service broadcast-client

3) Configuration on Device 1:

# Configure Device 1 to work in the broadcast client mode and receive broadcast messages on VLAN-interface2.

<Device1> system-view

[Device1] interface Vlan-interface 2

[Device1-Vlan-interface2] ntp-service broadcast-client

Because Device 1 and Device 3 are on different subnets, Device 1 cannot receive the broadcast messages from Device 3. Device 4 gets synchronized upon receiving a broadcast message from Device 3.

# Display the NTP status of Device 4 after clock synchronization.

[Device4] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 3.0.1.31

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: -16.0163 ms

Root delay: 31.00 ms

Root dispersion: 8.31 ms

Peer dispersion: 34.30 ms

Reference time: 16:01:51.713 UTC Sep 19 2005 (C6D95F6F.B6872B02)

As shown above, Device 4 has been synchronized to Device 3, and the clock stratum level of Device 4 is 3, while that of Device 3 is 2.

# Display the NTP session information of Device 4, which shows that an association has been set up between Device 4 and Device 3.

[Device4] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[12345] 3.0.1.31 127.127.1.0 2 254 64 62 -16.0 32.0 16.6

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured Total associations : 1

1.8.4 Configuring NTP Multicast Mode

I. Network requirements

The clock of Device 3 is synchronized, with a stratum level of 2, and Device 3 sends out multicast messages from VLAN-interface2. Device 4 and Device 1 receive multicast messages through their respective VLAN-interface2.

II. Network diagram

Figure 1-6 Network diagram for NTP multicast mode configuration

III. Configuration procedure

1) Configuration on Device 3:

The clock of Device 3 is synchronized, with a stratum level of 2.

# Configure Device 3 to work in the multicast server mode and send multicast messages through VLAN-interface2.

<Device3> system-view

[Device3] interface Vlan-interface 2

[Device3-Vlan-interface2] ntp-service multicast-server

2) Configuration on Device 4:

# Configure Device 4 to work in the multicast client mode and receive multicast messages on VLAN-interface2.

<Device4> system-view

[Device4] interface Vlan-interface 2

[Device4-Vlan-interface2] ntp-service multicast-client

Because Device 4 and Device 3 are on the same subnet, Device 4 can receive the multicast messages from Device 3 without being IGMP-enabled and can be synchronized to Device 3.

# Display the NTP status of Device 4 after clock synchronization.

[Device4] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 3.0.1.31

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: -16.0163 ms

Root delay: 31.00 ms

Root dispersion: 8.31 ms

Peer dispersion: 34.30 ms

Reference time: 16:01:51.713 UTC Sep 19 2005 (C6D95F6F.B6872B02)

As shown above, Device 4 has been synchronized to Device 3, and the clock stratum level of Device 4 is 3, while that of Device 3 is 2.

# Display the NTP session information of Device 4, which shows that an association has been set up between Device 4 and Device 3.

[Device4] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[1234] 3.0.1.31 127.127.1.0 2 254 64 62 -16.0 3231.0 16.6

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured

Total associations : 1

3) Configuration on Device 0:

Because Device 1 and Device 3 are on different subnets, you must enable IGMP on Device 1 and Device 0 before Device 1 can receive multicast messages from Device 3.

# Enable IP multicast routing and IGMP.

<Device0> system-view

[Device0] multicast routing-enable

[Device0] interface Vlan-interface 2

[Device0-Vlan-interface2] pim dm

[Device0-Vlan-interface2] quit

[Device0] interface Vlan-interface 3

[Device0-Vlan-interface3] pim dm

[Device0-Vlan-interface3] igmp enable

4) Configuration on Device 1:

# Enable IP multicast routing and IGMP.

<Device1> system-view

[Device1] multicast routing-enable

[Device1] interface Vlan-interface 3

[Device1-Vlan-interface3] igmp enable

[Device1-Vlan-interface3] igmp static-group 224.0.1.1

# Configure Device 1 to work in the multicast client mode and receive multicast messages on VLAN-interface3.

[Device1-Vlan-interface3] ntp-service multicast-client

# Display the NTP status of Device 1 after clock synchronization.

[Device1-Vlan-interface3] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 3.0.1.31

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: 21.9667 ms

Root delay: 18.47 ms

Root dispersion: 38.41 ms

Peer dispersion: 10.94 ms

Reference time: 16:02:49.713 UTC Sep 19 2005 (C6D95F6F.B6872B02)

As shown above, Device 1 has been synchronized to Device 3, and the clock stratum level of Device 1 is 3, while that of Device 3 is 2.

# Display the NTP session information of Device 1, which shows that an association has been set up between Device 1 and Device 3.

[Device1-Vlan-interface2] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[1234] 3.0.1.31 127.127.1.0 2 255 64 26 24.0 8.6 14.8

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured

Total associations : 1

& Note:

For details about the multicast function, see the Multicast part.

1.8.5 Configuring NTP Server/Client Mode with Authentication

I. Network requirements

The clock of Device 1 is synchronized, with a stratum level of 2. Device 1 is to be used as the NTP server of Device 2, with Device 2 as the client. NTP authentication is to be enabled for Device 1 and Device 2 at the same time.

II. Network diagram

Figure 1-7 Network diagram for configuration of NTP server/client mode with authentication

III. Configuration procedure

1) Configuration on Device 1:

The clock of Device 1 is synchronized, with a stratum level of 2.

2) Configuration on Device 2:

<Device2> system-view

# Enable NTP authentication on Device 2.

[Device2] ntp-service authentication enable

# Set an authentication key.

[Device2] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey

# Specify the key as a trusted key.

[Device2] ntp-service reliable authentication-keyid 42

# Specify Device 1 as the NTP server.

[Device2] ntp-service unicast-server 1.0.1.11 authentication-keyid 42

Before Device 2 can synchronize its clock to that of Device 1, you need to enable NTP authentication for Device 1.

Perform the following configuration on Device 1:

# Enable NTP authentication.

[Device1] ntp-service authentication enable

# Set an authentication key.

[Device1] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey

# Specify the key as a trusted key.

[Device1] ntp-service reliable authentication-keyid 42

# Display the NTP status of Device 2 after clock synchronization.

[Device2] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 1.0.1.11

Nominal frequence: 100.0000 Hz

Actual frequence: 100.0000 Hz

Clock precision: 2^18

Clock offset: 0.0000 ms

Root delay: 31.00 ms

Root dispersion: 1.05 ms

Peer dispersion: 7.81 ms

Reference time: 14:53:27.371 UTC Sep 19 2005 (C6D94F67.5EF9DB22)

As shown above, Device 2 has been synchronized to Device 1, and the clock stratum level of Device 2 is 3, while that of Device 1 is 2.

# Display the NTP session information of Device 2, which shows that an association has been set up Device 2 and Device 1.

[Device2] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[12345] 1.0.1.11 127.127.1.0 2 63 64 3 -2.9 31.0 16.5

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured Total associations : 1

1.8.6 Configuring the NTP Symmetric Mode with Authentication

I. Network requirements

II. Network diagram

Figure 1-8 Network diagram for NTP symmetric peers mode configuration with authentication

III. Configuration procedure

1) Configuration on Device 3:

The clock of Device 3 is synchronized, with a stratum level of 2.

# Configure NTP authentication

# Enable NTP authentication on Device 3.

<Device3> system-view

[Device3] ntp-service authentication enable

# Set an authentication key.

[Device3] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey

# Specify the key as a trusted key.

[Device3] ntp-service reliable authentication-keyid 42

2) Configuration on Device 4:

# Specify Device 3 as the NTP server of Device 4.

<Device4> system-view

[Device4] ntp-service unicast-server 3.0.1.31 authentication-keyid 42

# Enable NTP authentication

[Device4] ntp-service authentication enable

[Device4] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey

# Specify the key as a trusted key.

[Device3] ntp-service reliable authentication-keyid 42

3) Configuration on Device 5 (after Device 4 is synchronized to Device 3):

Device 5 is a switch on which you can configure local clock as reference clock.

# Specify the local clock as the reference source, with the stratum level of 1.

# Configure Device 4 as a symmetric peer after local synchronization.

[Device5] ntp-service unicast-peer 3.0.1.32 authentication-keyid 42

# Enable NTP authentication

<Device5> system-view

[Device5] ntp-service authentication enable

[Device5] ntp-service authentication-keyid 42 authentication-mode md5 aNiceKey

# Set the key as a trusted key.

[Device5] ntp-service reliable authentication-keyid 42

In the configuration above, Device 4 and Device 5 are configured as symmetric peers, with Device 5 in the symmetric-active mode and Device 4 in the symmetric-passive mode. Because the stratus level of Device 5 is 1 while that of Device 4 is 3, Device 4 is synchronized to Device 5.

# Display the NTP status of Device 4 after clock synchronization.

[Device4] display ntp-service status

Clock status: synchronized

Clock stratum: 2

Reference clock ID: 3.0.1.33

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: -21.1982 ms

Root delay: 15.00 ms

Root dispersion: 775.15 ms

Peer dispersion: 34.29 ms

Reference time: 15:22:47.083 UTC Sep 19 2005 (C6D95647.153F7CED)

As shown above, Device 4 has been synchronized to Device 5, and the clock stratum level of Device 4 is 2, while that of Device 5 is 1.

# Display the NTP session information of Device 4, which shows that an association has been set up between Device 4 and Device 5.

[Device4] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[245] 3.0.1.31 127.127.1.0 2 15 64 24 10535.0 19.6 14.5

[12345] 3.0.1.33 LOCL 1 14 64 27 -77.0 16.0 14.8

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured

Total associations : 2

1.8.7 Configuring NTP Broadcast Mode with Authentication

I. Network requirements

The clock of Device 3 is synchronized, with a stratum level of 3, and Device 3 sends out broadcast messages from VLAN-interface3. Device 4 is to receive broadcast client through VLAN-interface2, with NTP authentication enabled on both the server and client.

II. Network diagram

Figure 1-9 Network diagram for configuration of NTP broadcast mode with authentication

III. Configuration procedure

1) Configuration on Device 3:

The clock of Device 3 is synchronized, with a stratum level of 3.

# Configure NTP authentication

[Device3] ntp-service authentication enable

[Device3] ntp-service authentication-keyid 88 authentication-mode md5 123456

[Device3] ntp-service reliable authentication-keyid 88

# Specify Device 3 as an NTP broadcast server, and specify an authentication key.

[Device3] interface Vlan-interface 2

[Device3-Vlan-interface2] ntp-service broadcast-server authentication-keyid 88

2) Configuration on Device 4:

# Configure NTP authentication

<Device4> system-view

[Device4] ntp-service authentication enable

[Device4] ntp-service authentication-keyid 88 authentication-mode md5 123456

[Device4] ntp-service reliable authentication-keyid 88

# Configure Device 4 to work in the NTP broadcast client mode

[Device4] interface Vlan-interface 2

[Device4-Vlan-interface2] ntp-service broadcast-client

Now, Device 4 can receive broadcast messages through VLAN-interface2, and Device 3 can send broadcast messages through VLAN-interface2. Upon receiving a broadcast message from Device 3, Device 4 synchronizes its clock to that of Device 3.

# Display the NTP status of Device 4 after clock synchronization.

[Device4] display ntp-service status

Clock status: synchronized

Clock stratum: 4

Reference clock ID: 3.0.1.31

Nominal frequency: 100.0000 Hz

Actual frequency: 100.0000 Hz

Clock precision: 2^18

Clock offset: 0.0000 ms

Root delay: 31.00 ms

Root dispersion: 8.31 ms

Peer dispersion: 34.30 ms

Reference time: 16:01:51.713 UTC Sep 19 2005 (C6D95F6F.B6872B02)

As shown above, Device 4 has been synchronized to Device 3, and the clock stratum level of Device 4 is 4, while that of Device 3 is 3.

# Display the NTP session information of Device 4, which shows that an association has been set up between Device 4 and Device 3.

[Device4] display ntp-service sessions

source reference stra reach poll now offset delay disper

**************************************************************************

[12345] 3.0.1.31 127.127.1.0 3 254 64 62 -16.0 32.0 16.6

note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured

Total associations : 1

H3C S5500-SI Series Ethernet Switches Operation Manual-Release 1205-(V1.03)

1.1 NTP Overview

I. Server/client mode

II. Symmetric peers mode

III. Broadcast mode

IV. Multicast mode

1.3 Configuring the Operation Modes of NTP

I. Configuring a broadcast client

II. Configuring the broadcast server

I. Configuring a multicast client

II. Configuring the multicast server

1.4 Configuring Optional Parameters of NTP

1.5 Configuring Access-Control Rights

1.6 Configuring NTP Authentication

I. Configuring NTP authentication for a client

II. Configuring NTP authentication for a server

1.7 Displaying and Maintaining NTP

1.8 NTP Configuration Examples

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

I. Network requirements

II. Network diagram

III. Configuration procedure

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us