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 a network so that the devices can provide diverse applications based on the consistent time.

The time of a local system that runs NTP can be synchronized to other reference sources and used as a reference source to synchronize other clocks..

An administrator is unable to keep time synchronized among all the devices within a network by changing the system clock on each station, because this is a huge workload and cannot guarantee clock precision. NTP, however, allows quick clock synchronization within the entire network and ensures a high clock precision.

NTP is used when all devices within the network must be consistent in timekeeping, for example:

· In analysis of the log information and debugging information collected from different devices in network management, time must be used as reference basis.

· All devices must use the same reference clock in a charging system.

· To implement certain functions, such as scheduled restart of all devices within the network, all devices must be consistent in timekeeping.

· When multiple systems process a complex event in cooperation, these systems must use the same reference clock to ensure the correct execution sequence.

· For incremental backup between a backup server and clients, timekeeping must be synchronized between the backup server and all the clients.

NOTE:

· Stratum level of the clock source determines the clock precision. The value ranges from 1 to 16. The clock precision decreases from stratum 1 to 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.

· The WX3000E wireless switch switching engine cannot use its clock as the reference clock. It can synchronize other devices only when its clock is synchronized.

Advantages of NTP

· NTP uses a stratum to describe clock precision, and is able to synchronize time among all devices within the network.

· NTP supports access control and MD5 authentication.

· NTP can unicast, multicast or broadcast protocol messages.

How NTP works

Figure 1 shows the basic workflow of NTP. Device A and Device B are connected over a network. They have their own independent system clocks, which need to be automatically synchronized through NTP. Assume that:

· Prior to system clock synchronization between Device A and Device B, the clock of Device A is set to 10:00:00 am while that of Device B is set to 11:00:00 am.

· Device B is used as the NTP time server, namely, Device A synchronizes its clock to that of Device B.

· It takes 1 second for an NTP message to travel from one device to the other.

Figure 1 Basic work flow of NTP

The process of system clock synchronization is as follows:

· Device A sends Device B an NTP message, which is timestamped when it leaves Device A. The time stamp is 10:00:00 am (T1).

· When this NTP message arrives at Device B, it is timestamped by Device B. The timestamp is 11:00:01 am (T2).

· When the NTP message leaves Device B, Device B timestamps it. The timestamp is 11:00:02 am (T3).

· When Device A receives the NTP message, the local time of Device A is 10:00:03 am (T4).

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

· The roundtrip delay of NTP message: Delay = (T4–T1) – (T3-T2) = 2 seconds.

· Time difference between Device A and Device B: Offset = ((T2-T1) + (T3-T4))/2 = 1 hour.

Based on these parameters, Device A can synchronize its own clock to the clock of Device B.

This is only a rough description of the work mechanism of NTP. For more information, see RFC 1305.

NTP message format

NTP uses two types of messages: clock synchronization messages and NTP control messages. An NTP control message is used in environments where network management is needed. Because it is not essential for clock synchronization, it is not described 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 2.

Figure 2 Clock synchronization message format

Main fields are described as follows:

· LI (Leap Indicator): A 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.

· VN (Version Number): A 3-bit version number that indicates the version of NTP. The latest version is version 3.

· Mode: A 3-bit code that indicates 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.

· Stratum: An 8-bit integer that indicates the stratum level of the local clock, with the value ranging from 1 to 16. 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.

· Poll: An 8-bit signed integer that indicates the maximum interval between successive messages, which is called the poll interval.

· Precision: An 8-bit signed integer that indicates the precision of the local clock.

· Root Delay: Roundtrip delay to the primary reference source.

· Root Dispersion: The maximum error of the local clock relative to the primary reference source.

· Reference Identifier: Identifier of the particular reference source.

· Reference Timestamp: The local time at which the local clock was last set or corrected.

· Originate Timestamp: The local time at which the request departed from the client for the service host.

· Receive Timestamp: The local time at which the request arrived at the service host.

· Transmit Timestamp: The local time at which the reply departed from the service host for the client.

· Authenticator: authentication information.

Operation modes of NTP

Devices that run NTP can implement clock synchronization in one of the following modes:

· Client/server mode

· Symmetric peers mode

· Broadcast mode

· Multicast mode

You can select operation modes of NTP as needed. If the IP address of the NTP server or peer is unknown and many devices in the network need to be synchronized, you can adopt the broadcast or multicast mode; while in the client/server and symmetric peers modes, a device is synchronized from the specified server or peer, so clock reliability is enhanced.

Client/server mode

Figure 3 Client/server mode

When working in client/server mode, a client sends a clock synchronization message to servers, with the Mode field in the message set to 3 (client mode). Upon receiving the message, the servers automatically work in 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 client/server mode, a client can be synchronized to a server, but versa server cannot be synchronized to a client.

Symmetric peers mode

Figure 4 Symmetric peers mode

In symmetric peers mode, devices that work in symmetric active mode and symmetric passive mode exchange NTP messages with the Mode field 3 (client mode) and 4 (server mode). Then the device that works in symmetric active mode periodically sends clock synchronization messages, with the Mode field in the messages set to 1 (symmetric active). The device that receives the messages automatically enters symmetric passive mode and sends a reply, with the Mode field in the message set to 2 (symmetric passive). This exchange of messages establishes symmetric peers mode between the two devices, so the two devices can synchronize, or be synchronized by, each other. If the clocks of both devices have been synchronized, the device whose local clock has a lower stratum level synchronizes the clock of the other device.

Broadcast mode

Figure 5 Broadcast mode

In broadcast mode, a server periodically sends clock synchronization messages to 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. When 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 broadcast client mode. The client continues listening to broadcast messages, and synchronizes its local clock based on the received broadcast messages.

Multicast mode

Figure 6 Multicast mode

In 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. When 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 server. Then, the client enters multicast client mode. It continues listening to multicast messages, and synchronizes its local clock based on the received multicast messages.

NOTE:

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.

NTP configuration task list

Complete the following tasks to configure NTP:

Task	Remarks
Configuring the operation modes of NTP	Required
Configuring optional parameters of NTP	Optional
Configuring access-control rights	Optional
Configuring NTP authentication	Optional

Configuring the operation modes of NTP

Devices can implement clock synchronization in one of the following modes:

· Client/server mode

· Symmetric mode

· Broadcast mode

· Multicast mode

For client/server mode or symmetric mode, you need to configure only clients or symmetric-active peers; for 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.

· A dynamic association is a temporary association created by the system during operation. A dynamic association is removed if the system fails to receive messages from it over a specific long time.

· In client/server mode, for example, when you execute a command to synchronize the time to a server, the system creates a static association, and the server simply responds passively upon the receipt of a message, rather than creating an association (static or dynamic). In symmetric mode, static associations are created at the symmetric-active peer side, and dynamic associations are created at the symmetric-passive peer side. In broadcast or multicast mode, static associations are created at the server side, and dynamic associations are created at the client side.

Configuring NTP client/server mode

For devices working in client/server mode, make configurations on the clients.

Follow these steps to specify an NTP server on the 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 No NTP server is specified by default.

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

No NTP server is specified by default.

NOTE:

· In the ntp-service unicast-server command, ip-address must be a unicast address, rather than a broadcast address, a multicast address or the IP address of the local clock.

· When the source interface for NTP messages is specified by the source-interface keyword, the source IP address of the NTP messages is configured as the primary IP address of the specified interface.

· 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 that server’s clock.

· You can configure multiple servers by repeating the ntp-service unicast-server command. The clients will select the optimal reference source.

Configuring the NTP symmetric peers mode

For devices working in symmetric mode, specify a symmetric-passive peer on a symmetric-active peer.

Following these steps to specify a symmetric-passive peer on the active peer:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Specify a 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 No symmetric-passive peer is specified by default.

To do…

Use the command…

Remarks

Enter system view

system-view

—

Specify a 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

No symmetric-passive peer is specified by default.

NOTE:

· In symmetric mode, use any NTP configuration command in Configuring the operation modes of NTP to enable NTP; otherwise, a symmetric-passive peer will not process NTP messages from a symmetric-active peer.

· In the ntp-service unicast-peer command, ip-address must be a unicast address, rather than a broadcast address, a multicast address or the IP address of the local clock.

· Typically, at least one of the symmetric-active and symmetric-passive peers has been synchronized; otherwise the clock synchronization will not proceed.

· You can configure multiple symmetric-passive peers by repeating the ntp-service unicast-peer command.

Configuring NTP broadcast mode

The broadcast server periodically sends NTP broadcast messages to the broadcast address 255.255.255.255. After receiving the messages, the device working in NTP broadcast client mode sends a reply and synchronizes its local clock.

For devices working in broadcast mode, configure both the server and clients. Because an interface needs 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.

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 device to work in NTP broadcast client mode	ntp-service broadcast-client	Required

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 device to work in NTP broadcast server mode	ntp-service broadcast-server [ authentication-keyid keyid \| version number ] *	Required

NOTE:

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

Configuring NTP multicast mode

The multicast server periodically sends NTP multicast messages to multicast clients, which send replies after receiving the messages and synchronize their local clocks.

For devices working in multicast mode, configure both the server and clients. The NTP multicast mode must be configured in the specific interface view.

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 device to work in NTP multicast client mode	ntp-service multicast-client [ ip-address ]	Required

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 device to work in 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 when its clock has been synchronized.

· You can configure up to 1024 multicast clients, among which 128 can take effect at the same time.

Configuring optional parameters of NTP

Specifying the source interface for NTP messages

If you specify the source interface for NTP messages, the device sets the source IP address of the NTP messages as the primary IP address of the specified interface when sending the NTP messages.

When the device responds to an NTP request received, the source IP address of the NTP response is always the IP address of the interface that received the NTP request.

Following these steps to specify the source interface for NTP messages:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Specify the source interface for NTP messages	ntp-service source-interface interface-type interface-number	Required By default, no source interface is specified for NTP messages, and the system uses the IP address of the interface determined by the matching route as the source IP address of NTP messages.

To do…

Use the command…

Remarks

Enter system view

system-view

—

Specify the source interface for NTP messages

ntp-service source-interface interface-type interface-number

Required

By default, no source interface is specified for NTP messages, and the system uses the IP address of the interface determined by the matching route as the source IP address of NTP messages.

CAUTION:

· If you have specified the source interface for NTP messages in the ntp-service unicast-server or ntp-service unicast-peer command, the interface specified in the ntp-service unicast-server or ntp-service unicast-peer command serves as the source interface of NTP messages.

· If you have configured the ntp-service broadcast-server or ntp-service multicast-server command, the source interface of the broadcast or multicast NTP messages is the interface configured with the respective command.

· If the specified source interface for NTP messages is down, the source IP address for an NTP message that is sent out is the primary IP address of the outgoing interface of the NTP message.

Disabling an interface from receiving NTP messages

When NTP is enabled, NTP messages can be received from all the interfaces by default, and you can disable an interface from receiving NTP messages through the following configuration.

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.

Configuring the maximum number of dynamic sessions allowed

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

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

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:

· query: Control query permitted. This level of right permits the peer devices to perform control query to the NTP service on the local device but does not permit a peer device to synchronize its clock to that of 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.

· synchronization: Server access only. This level of right permits a peer device to synchronize its clock to that of the local device but does not permit the peer devices to perform control query.

· server: Server access and query permitted. This level of right permits the peer devices to perform synchronization and control query to the local device but does not permit the local device to synchronize its clock to that of a peer device.

· peer: Full access. This level of right permits the peer devices to perform synchronization and control query to the local device and also permits the local device to synchronize its clock to that of a 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 performs an access-control right match and uses the first matched right.

Configuration prerequisites

Prior to configuring the NTP service access-control right to the local device, create and configure an ACL associated with the access-control right. For more information about ACLs, see the ACL and QoS Configuration Guide.

Configuration procedure

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 for a peer device to access 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 for a peer device to access 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 level of security protection for a system running NTP. A more secure method is identity authentication.

Configuring NTP authentication

NTP authentication should be enabled for a system running NTP in a network where there is a high security demand. It enhances the network security by means of client-server key authentication, which prohibits a client from synchronizing with a device that has failed authentication.

Configuration prerequisites

The configuration of NTP authentication involves configuration tasks to be implemented on the client and on the server.

When configuring NTP authentication, note the following:

· For all synchronization modes, when you enable the NTP authentication feature, configure an authentication key and specify it as a trusted key. In other words, 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.

· For client/server mode or symmetric mode, 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.

· For broadcast server mode or multicast server mode, 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.

· For client/server mode, if the NTP authentication feature has not been enabled for the client, the client can synchronize with the server regardless of whether the NTP authentication feature has been enabled for the server or not. 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.

· For all synchronization modes, the server side configuration and the client side configuration must be consistently.

Configuration procedure

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 By default, no authentication key is configured to be trusted.
Associate the specified key with an NTP server	Client/server 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.
Associate the specified key with an NTP server	Symmetric peers mode: ntp-service unicast-peer { ip-address \| peer-name } authentication-keyid keyid

NOTE:

After you enable the NTP authentication feature for the client, make sure that the authentication key you configure for the client is the same as on the server, and specify that the authentication key is trusted. Otherwise, the client cannot be synchronized to the server.

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 By default, no authentication key is configured to be trusted.
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.
Associate the specified key with an NTP server	Multicast server mode: ntp-service multicast-server authentication-keyid keyid

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.

Displaying and maintaining NTP

To do…	Use the command…	Remarks
Display information about NTP service status	display ntp-service status [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about NTP sessions	display ntp-service sessions [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the brief information about the NTP servers from the local device back to the primary reference source	display ntp-service trace [ \| { begin \| exclude \| include } regular-expression ]	Available in any view

NTP configuration examples

Configuring NTP client/server mode

Network requirements

Perform the following configurations to synchronize the time between Device B and Device A:

· As shown in Figure 7, the local clock of Device A is to be used as a reference source, with the stratum level of 2.

· Device B works in client/server mode and Device A is to be used as the NTP server of Device B.

Figure 7 Network diagram for NTP client/server mode configuration

Configuration procedure

1. Set the IP address for each interface as shown in Figure 7. The configuration procedure is omitted.

2. Configure Device B:

# View the NTP status of Device B before clock synchronization.

<DeviceB> display ntp-service status

Clock status: unsynchronized

Clock stratum: 16

Reference clock ID: none

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

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 A as the NTP server of Device B so that Device B is synchronized to Device A.

<DeviceB> system-view

[DeviceB] ntp-service unicast-server 1.0.1.11

# View the NTP status of Device B after clock synchronization.

[DeviceB] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 1.0.1.11

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

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)

The output shows that Device B has been synchronized to Device A, and the clock stratum level of Device B is 3, while that of Device A is 2.

# View the NTP session information of Device B, which shows that an association has been set up between Device B and Device A.

[DeviceB] 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 -75.5 31.0 16.5

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

Total associations : 1

Configuring the NTP symmetric mode

Network requirements

Perform the following configurations to synchronize time among devices:

· As shown in Figure 8, the local clock of Device A is to be configured as a reference source, with the stratum level of 2.

· Device B works in client mode and Device A is to be used as the NTP server of Device B.

· Device C works in symmetric-active mode and Device B acts as the peer of Device C.

Figure 8 Network diagram for NTP symmetric peers mode configuration

Configuration procedure

1. Set the IP address for each interface. The configuration procedure is omitted.

2. Configure Device B:

# Specify Device A as the NTP server of Device B.

<DeviceB> system-view

[DeviceB] ntp-service unicast-server 3.0.1.31

3. # View the NTP status of Device B after clock synchronization.

[DeviceB] 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.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)

The output shows that Device B has been synchronized to Device A, and the clock stratum level of Device B is 3, while that of Device A is 2.

4. Configure Device C (after Device B is synchronized to Device A):

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

[DeviceC] ntp-service unicast-peer 3.0.1.32

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

# View the NTP status of Device B after clock synchronization.

[DeviceC] display ntp-service status

Clock status: synchronized

Clock stratum: 4

Reference clock ID: 3.0.1.32

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)

The output shows that Device C has been synchronized to Device B, and the clock stratum level of Device C is 4, while that of Device B is 3.

# View the NTP session information of Device C, which shows that an association has been set up between Device C and Device B.

[DeviceC] display ntp-service sessions

source reference stra reach poll now offset delay disper

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

[12345] 3.0.1.32 3.0.1.31 3 3 64 16 -6.4 4.8 1.0

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

Total associations : 2

Configuring NTP broadcast mode

Network requirements

As shown in Figure 9, Switch C functions as the NTP server for multiple devices on a network segment and synchronizes the time among multiple devices.

· Switch C’s local clock is to be used as a reference source, with the stratum level of 2.

· Switch C works in broadcast server mode and sends out broadcast messages from VLAN-interface 2.

· Switch A and Switch B work in broadcast client mode, and listen to broadcast messages through their VLAN-interface 2 respectively.

Figure 9 Network diagram for NTP broadcast mode configuration

Configuration procedure

1. Set the IP address for each interface as shown in Figure 9. The configuration procedure is omitted.

2. Configure Switch C:

# Configure Switch C to work in broadcast server mode and send broadcast messages through VLAN-interface 2.

[SwitchC] interface vlan-interface 2

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

3. Configure Switch A:

# Configure Switch A to work in broadcast client mode and receive broadcast messages on VLAN-interface 2.

<SwitchA> system-view

[SwitchA] interface vlan-interface 2

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

4. Configure Switch B:

# Configure Switch B to work in broadcast client mode and receive broadcast messages on VLAN-interface 2.

<SwitchB> system-view

[SwitchB] interface vlan-interface 2

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

Switch A and Switch B get synchronized upon receiving a broadcast message from Switch C.

# Take Switch A as an example. View the NTP status of Switch A after clock synchronization.

[SwitchA-Vlan-interface2] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 3.0.1.31

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

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, Switch A has been synchronized to Switch C, and the clock stratum level of Switch A is 3, while that of Switch C is 2.

# View the NTP session information of Switch A, which shows that an association has been set up between Switch A and Switch C.

[SwitchA-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 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

Configuring NTP multicast mode

Network requirements

As shown in Figure 10, Switch C functions as the NTP server for multiple devices on different network segments and synchronizes the time among multiple devices.

· Switch C’s local clock is to be used as a reference source, with the stratum level of 2.

· Switch C works in multicast server mode and sends out multicast messages from VLAN-interface 2.

· Switch A and Switch D work in multicast client mode and receive multicast messages through VLAN-interface 3 and VLAN-interface 2 respectively.

Figure 10 Network diagram for NTP multicast mode configuration

Configuration procedure

1. Set the IP address for each interface as shown in Figure 10. The configuration procedure is omitted.

2. Configure Switch C:

# Configure Switch C to work in multicast server mode and send multicast messages through VLAN-interface 2.

[SwitchC] interface vlan-interface 2

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

3. Configure Switch D:

# Configure Switch D to work in multicast client mode and receive multicast messages on VLAN-interface 2.

<SwitchD> system-view

[SwitchD] interface vlan-interface 2

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

Because Switch D and Switch C are on the same subnet, Switch D can receive the multicast messages from Switch C without being enabled with the multicast functions and can be synchronized to Switch C.

# View the NTP status of Switch D after clock synchronization.

[SwitchD-Vlan-interface2] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 3.0.1.31

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

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, Switch D has been synchronized to Switch C, and the clock stratum level of Switch D is 3, while that of Switch C is 2.

# View the NTP session information of Switch D, which shows that an association has been set up between Switch D and Switch C.

[SwitchD-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 254 64 62 -16.0 31.0 16.6

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

Total associations : 1

4. Configure Switch B:

Because Switch A and Switch C are on different subnets, you must enable the multicast functions on Switch B before Switch A can receive multicast messages from Switch C.

# Enable IP multicast routing and IGMP.

<SwitchB> system-view

[SwitchB] multicast routing-enable

[SwitchB] interface vlan-interface 2

[SwitchB-Vlan-interface2] pim dm

[SwitchB-Vlan-interface2] quit

[SwitchB] vlan 3

[SwitchB-vlan3] port gigabitethernet 1/0/1

[SwitchB-vlan3] quit

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] igmp enable

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

[SwitchB-Vlan-interface3] quit

[SwitchB] interface gigabitethernet 1/0/1

[SwitchB-GigabitEthernet1/0/1] igmp-snooping static-group 224.0.1.1 vlan 3

5. Configure Switch A:

<SwitchA> system-view

[SwitchA] interface vlan-interface 3

# Configure Switch A to work in multicast client mode and receive multicast messages on VLAN-interface 3.

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

# View the NTP status of Switch A after clock synchronization.

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

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 3.0.1.31

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

Clock offset: 0.0000 ms

Root delay: 40.00 ms

Root dispersion: 10.83 ms

Peer dispersion: 34.30 ms

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

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

# View the NTP session information of Switch A, which shows that an association has been set up between Switch A and Switch C.

[SwitchA-Vlan-interface3] 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 -16.0 40.0 16.6

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

Total associations : 1

NOTE:

For more information about how to configure IGMP, see the IP Multicast Configuration Guide.

Configuring NTP client/server mode with authentication

Network requirements

As shown in Figure 11, perform the following configurations to synchronize the time between Device B and Device A and ensure network security.

· The local clock of Device A is to be configured as a reference source, with the stratum level of 2.

· Device B works in client mode and Device A is to be used as the NTP server of Device B, with Device B as the client.

· NTP authentication is to be enabled on both Device A and Device B.

Figure 11 Network diagram for configuration of NTP client/server mode with authentication

Configuration procedure

1. Set the IP address for each interface as shown in Figure 11. The configuration procedure is omitted.

2. Configure Device B:

<DeviceB> system-view

# Enable NTP authentication on Device B.

[DeviceB] ntp-service authentication enable

# Set an authentication key.

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

# Specify the key as a trusted key.

[DeviceB] ntp-service reliable authentication-keyid 42

# Specify Device A as the NTP server of Device B.

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

Before Device B can synchronize its clock to that of Device A, enable NTP authentication for Device A.

Perform the following configuration on Device A:

# Enable NTP authentication.

[DeviceA] ntp-service authentication enable

# Set an authentication key.

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

# Specify the key as a trusted key.

[DeviceA] ntp-service reliable authentication-keyid 42

# View the NTP status of Device B after clock synchronization.

[DeviceB] display ntp-service status

Clock status: synchronized

Clock stratum: 3

Reference clock ID: 1.0.1.11

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

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 B has been synchronized to Device A, and the clock stratum level of Device B is 3, while that of Device A is 2.

# View the NTP session information of Device B, which shows that an association has been set up Device B and Device A.

[DeviceB] 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 -75.5 31.0 16.5

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

Total associations : 1

Configuring NTP broadcast mode with authentication

Network requirements

As shown in Figure 12, Switch C functions as the NTP server for multiple devices on different network segments and synchronizes the time among multiple devices. Switch B authentications the reference source.

· Switch C’s local clock is to be used as a reference source, with the stratum level of 3.

· Switch C works in broadcast server mode and sends out broadcast messages from VLAN-interface 2.

· Switch D works in broadcast client mode and receives broadcast messages through VLAN-interface 2.

· NTP authentication is enabled on both Switch C and Switch D.

Figure 12 Network diagram for configuration of NTP broadcast mode with authentication

Configuration procedure

1. Set the IP address for each interface. The configuration procedure is omitted.

2. Configure Switch C

# Enable NTP authentication on Switch C. Configure an NTP authentication key, with the key ID of 88 and key value of 123456. Specify the key as a trusted key.

[SwitchC] ntp-service authentication enable

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

[SwitchC] ntp-service reliable authentication-keyid 88

# Specify Switch C as an NTP broadcast server, and associate the key 88 with Switch C.

[SwitchC] interface vlan-interface 2

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

3. Configure Switch D

# Enable NTP authentication on Switch D. Configure an NTP authentication key, with the key ID of 88 and key value of 123456. Specify the key as a trusted key.

<SwitchD> system-view

[SwitchD] ntp-service authentication enable

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

[SwitchD] ntp-service reliable authentication-keyid 88

# Configure Switch D to work in the NTP broadcast client mode and use VLAN-interface 2 to receive NTP broadcast packets.

[SwitchD] interface vlan-interface 2

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

# View the status of Switch D after clock synchronization.

[SwitchD-Vlan-interface2] display ntp-service status

Clock status: synchronized

Clock stratum: 4

Reference clock ID: 3.0.1.31

Nominal frequency: 64.0000 Hz

Actual frequency: 64.0000 Hz

Clock precision: 2^7

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)

The output shows that Switch D has been synchronized to Switch C, and the clock stratum level of Switch D is 4, while that of Switch C is 3.

# View the NTP session information of Switch D, which shows that an association has been set up between Switch D and Switch C.

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

source reference stra reach poll now offset delay disper

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

[1234] 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

08-Network Management and Monitoring @CG@

Operation modes of NTP

Client/server mode

Symmetric peers mode

Broadcast mode

Multicast mode

NTP configuration task list

Configuring the operation modes of NTP

Configuring a broadcast client

Configuring the broadcast server

Configuring a multicast client

Configuring the multicast server

Configuring optional parameters of NTP

Configuring access-control rights

Configuring NTP authentication

Configuring NTP authentication for a client

Configuring NTP authentication for a server

Displaying and maintaining NTP

NTP configuration examples

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us