- Table of Contents
-
- 12-Network Management and Monitoring Configuration Guide
- 00-Preface
- 01-System Maintenance and Debugging Configuration
- 02-NQA Configuration
- 03-NTP Configuration
- 04-Clock Monitoring Configuration
- 05-IPC Configuration
- 06-SNMP Configuration
- 07-RMON Configuration
- 08-Sampler Configuration
- 09-Mirroring Configuration
- 10-NetStream Configuration
- 11-IPv6 NetStream Configuration
- 12-Protocol Packet Statistics Configuration
- 13-Information Center Configuration
- 14-Flow Logging Configuration
- Related Documents
-
Title | Size | Download |
---|---|---|
03-NTP Configuration | 503.13 KB |
Contents
Configuring the operation modes of NTP
Configuring NTP client/server mode
Configuring the NTP symmetric mode
Configuring NTP broadcast mode
Configuring NTP multicast mode
Configuring the local clock as a reference source
Configuring optional parameters of NTP
Specifying the source interface for NTP messages
Disabling an interface from receiving NTP messages
Configuring the maximum number of dynamic sessions allowed
Configuring access-control rights
Configuring NTP authentication
Configuring NTP authentication in client/server mode
Configuring NTP authentication in symmetric peers mode
Configuring NTP authentication in broadcast mode
Configuring NTP authentication in multicast mode
Displaying and maintaining NTP
Configuring NTP client/server mode
Configuring the NTP symmetric mode
Configuring NTP broadcast mode
Configuring NTP multicast mode
Configuring NTP client/server mode with authentication
Configuring NTP broadcast mode with authentication
Configuring MPLS VPN time synchronization in client/server mode
Configuring MPLS VPN time synchronization in symmetric peers mode
NTP overview
Defined in RFC 1305, the Network Time Protocol (NTP) synchronizes timekeeping among distributed time servers and clients. NTP runs over the User Datagram Protocol (UDP), using UDP port 123.
The purpose of using NTP is to keep consistent timekeeping among all clock-dependent devices within the network so that the devices can provide diverse applications based on the consistent time.
For a local system running NTP, its time can be synchronized by other reference sources and can be used as a reference source to synchronize other clocks.
NTP applications
An administrator can by no means keep synchronized time among all the devices within a network by changing the system clock on each station, because this is a huge amount of workload and cannot guarantee the clock precision. NTP, however, allows quick clock synchronization within the entire network while it ensures a high clock precision.
NTP is used when all devices within the network must be consistent in timekeeping, for example:
· 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 that same reference clock to ensure the correct execution sequence.
· For increment backup between a backup server and clients, timekeeping must be synchronized between the backup server and all the clients.
Advantages of NTP:
· NTP uses a stratum to describe the 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 work flow of NTP. Device A and Device B are interconnected over a network. They have their own independent system clocks, which need to be automatically synchronized through NTP. For an easy understanding, we assume that:
· 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 details, refer to RFC 1305.
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 is 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 2.
Figure 2 Clock synchronization message format
Main fields are described as follows:
· LI—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—A 3-bit version number, indicating the version of NTP. The latest version is version 3.
· 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.
· Stratum—An 8-bit integer indicating the stratum level of the local clock, with the value ranging from 1 to 16. The clock precision decreases from stratum 1 through stratum 16. A stratum 1 clock has the highest precision, and a stratum 16 clock is not synchronized and cannot be used as a reference clock.
· Poll—An 8-bit signed integer indicating the poll interval, namely the maximum interval between successive messages.
· Precision—An 8-bit signed integer indicating 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 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 the service host for the client.
· Authenticator—Authentication information.
Operation modes of NTP
Devices running 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. In case that the IP address of the NTP server or peer is unknown and many devices in the network need to be synchronized, you can adopt the broadcast or multicast mode; while in the client/server and symmetric peers modes, a device is synchronized from the specified server or peer, and thus clock reliability is enhanced.
Client/server mode
Figure 3 Client/server mode
When working in the client/server mode, a client sends a clock synchronization message to servers, with the Mode field in the message set to 3 (client mode). Upon receiving the message, the servers automatically work in the server mode and send a reply, with the Mode field in the messages set to 4 (server mode). Upon receiving the replies from the servers, the client performs clock filtering and selection, and 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.
Symmetric peers mode
Figure 4 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.
Broadcast mode
Figure 5 Broadcast mode
In the broadcast mode, a server periodically sends clock synchronization messages to the broadcast address 255.255.255.255, with the Mode field in the messages set to 5 (broadcast mode). Clients listen to the broadcast messages from servers. After a client receives the first broadcast message, the client and the server start to exchange messages, with the Mode field set to 3 (client mode) and 4 (server mode) to calculate the network delay between client and the server. Then, the client enters the broadcast client mode and continues listening to broadcast messages, and synchronizes its local clock based on the received broadcast messages.
Multicast mode
Figure 6 Multicast mode
In the multicast mode, a server periodically sends clock synchronization messages to the user-configured multicast address, or, if no multicast address is configured, to the default NTP multicast address 224.0.1.1, with the Mode field in the messages set to 5 (multicast mode). Clients listen to the multicast messages from servers. After a client receives the first multicast message, the client and the server start to exchange messages, with the Mode field set to 3 (client mode) and 4 (server mode) to calculate the network delay between client and the server. Then, the client enters the multicast client mode and continues listening to multicast messages, and synchronizes its local clock based on the received multicast messages.
|
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-supported MPLS L3VPN
When operating in client/server mode or symmetric mode, NTP supports MPLS L3VPN, and thus realizes clock synchronization within an MPLS VPN network. In other words, network devices (CEs and PEs) at different physical location can get their clocks synchronized through NTP, as long as they are in the same VPN. The specific functions are as follows:
· The NTP client on a customer edge device (CE) can be synchronized to the NTP server on another CE.
· The NTP client on a CE can be synchronized to the NTP server on a provider edge device (PE).
· The NTP client on a PE can be synchronized to the NTP server on a CE through a designated VPN.
· The NTP client on a PE can be synchronized to the NTP server on another PE through a designated VPN.
· The NTP server on a PE can synchronize the NTP clients on multiple CEs in different VPNs.
|
NOTE: · A CE is a device that has an interface directly connecting to the service provider (SP). A CE is not “aware of” the presence of the VPN. · A PE is a device that directly connecting to CEs. In an MPLS network, all events related to VPN processing occur on the PE. |
NTP configuration task list
Complete these tasks to configure NTP:
Task |
Remarks |
Required |
|
Optional |
|
Optional |
|
Optional |
|
Optional |
Configuring the operation modes of NTP
Routers can implement clock synchronization in one of the following modes:
· Client/server mode
· Symmetric mode
· Broadcast mode
· Multicast mode
For the client/server 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 router 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 client/server mode, for example, when you carry out a command to synchronize the time to a server, the system will create a static association, and the server will just respond passively upon the receipt of a message, rather than creating an association (static or dynamic). In the symmetric mode, static associations will be created at the symmetric-active peer side, and dynamic associations will be created at the symmetric-passive peer side; in the broadcast or multicast mode, static associations will be created at the server side, and dynamic associations will be created at the client side. |
Configuring NTP client/server mode
For routers working in the client/server mode, make the following configurations on the clients.
To configure an NTP client:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify an NTP server for the router. |
ntp-service unicast-server [ vpn-instance vpn-instance-name ] { ip-address | server-name } [ authentication-keyid keyid | priority | source-interface interface-type interface-number | version number ] * |
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 argument, the source IP address of the NTP messages is configured as the primary IP address of the specified interface. · A router can act as a server to synchronize the clock of other routers 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. · You can configure multiple servers by repeating the ntp-service unicast-server command. The clients will choose the optimal reference source. |
Configuring the NTP symmetric mode
For routers working in the symmetric mode, you need to specify a symmetric-passive on a symmetric-active peer.
To configure a symmetric-active router:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify a symmetric-passive peer for the router. |
ntp-service unicast-peer [ vpn-instance vpn-instance-name ] { ip-address | peer-name } [ authentication-keyid keyid | priority | source-interface interface-type interface-number | version number ] * |
No symmetric-passive peer is specified by default. |
|
NOTE: · In symmetric peers mode, you should use the ntp-service refclock-master command or any NTP configuration command in Configuring the operation modes of NTP to enable NTP; otherwise, a symmetric-passive peer will not process NTP 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. · When the source interface for NTP messages is specified by the source-interface argument, the source IP address of the NTP message is configured as the primary IP address of the specified interface. · 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 router working in NTP broadcast mode sends a reply and synchronizes its local clock.
For routers working in the broadcast mode, you need to configure both the server and clients. Because an interface need to be specified on the broadcast server for sending NTP broadcast messages and an interface also needs to be specified on each broadcast client for receiving broadcast messages, the NTP broadcast mode can be configured only in the specific interface view.
Configuring a broadcast client
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
Enter the interface used to receive NTP broadcast messages |
3. Configure the router to work in the NTP broadcast client mode. |
ntp-service broadcast-client |
N/A |
Configuring the broadcast server
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
Enter the interface used to send NTP broadcast messages |
3. Configure the router to work in the NTP broadcast server mode. |
ntp-service broadcast-server [ authentication-keyid keyid | version number ]* |
N/A |
|
NOTE: A broadcast server can synchronize broadcast clients only after 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 routers 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
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
Enter the interface used to receive NTP multicast messages |
3. Configure the router to work in the NTP multicast client mode. |
ntp-service multicast-client [ ip-address ] |
N/A |
Configuring the multicast server
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
Enter the interface used to send NTP multicast message |
3. Configure the router to work in the NTP multicast server mode. |
ntp-service multicast-server [ ip-address ] [ authentication-keyid keyid | ttl ttl-number | version number ] * |
N/A |
|
NOTE: · A multicast server can synchronize broadcast clients only after its clock has been synchronized. · You can configure up to 1024 multicast clients, among which 128 can take effect at the same time. |
Configuring the local clock as a reference source
A network router can get its clock synchronized in one of the following two ways:
· Synchronized to the local clock, which as the reference source.
· Synchronized to another router on the network in any of the four NTP operation modes previously described.
If you configure two synchronization modes, the router will choose the optimal clock as the reference source.
To configure the local clock as a reference source:
Step |
Command |
1. Enter system view. |
system-view |
2. Configure the local clock as a reference source. |
ntp-service refclock-master [ ip-address ] [ stratum ] |
|
NOTE: · In this command, ip-address must be 127.127.1.u, where u ranges from 0 to 3, representing the NTP process ID. · Typically, the stratum level of the NTP server which is synchronized from an authoritative clock (such as an atomic clock) is set to 1. This NTP server operates as the primary reference source on the network; and other routers synchronize themselves to it. The synchronization distances between the primary reference source and other routers on the network, namely, the number of NTP servers on the NTP synchronization paths, determine the clock stratum levels of the routers. · After you have configured the local clock as a reference clock, the local router can act as a reference clock to synchronize other routers in the network. Therefore, perform this configuration with caution to avoid clock errors of the routers in the network. |
Configuring optional parameters of NTP
Specifying the source interface for NTP messages
If you specify the source interface for NTP messages, the router 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 router 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.
To specify the source interface for NTP messages:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Specify the source interface for NTP message. |
ntp-service source-interface interface-type interface-number |
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.
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enter interface view. |
interface interface-type interface-number |
N/A |
3. Disable the interface from receiving NTP messages. |
ntp-service in-interface disable |
An interface is enabled to receive NTP messages by default |
Configuring the maximum number of dynamic sessions allowed
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the maximum number of dynamic sessions allowed to be established locally. |
ntp-service max-dynamic-sessions number |
100 by default |
Configuring access-control rights
With the following command, you can configure the NTP service access-control right to the local router. There are four access-control rights, as follows:
· query—Control query permitted. This level of right permits the peer router to perform control query to the NTP service on the local router but does not permit the peer router to synchronize its clock to the local router. 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 the peer router to synchronize its clock to the local router but does not permit the peer router to perform control query.
· server—Server access and query permitted. This level of right permits the peer router to perform synchronization and control query to the local router but does not permit the local router to synchronize its clock to the peer router.
· peer—Full access. This level of right permits the peer router to perform synchronization and control query to the local router and also permits the local router to synchronize its clock to the peer router.
From the highest NTP service access-control right to the lowest one are peer, server, synchronization, and query. When a router receives an NTP request, it performs an access-control right match and uses the first matched right. If no matched right is found, the router discards the NTP request.
Configuration prerequisites
Prior to configuring the NTP service access-control right to the local router, you need to create and configure an ACL associated with the access-control right. For more information about ACLs, see ACL and QoS Configuration Guide.
Configuration procedure
To configure the NTP service access-control right to the local router:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Configure the NTP service access-control right for a peer router to access the local router. |
ntp-service access { peer | query | server | synchronization } acl-number |
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. |
Configuring NTP authentication
NTP authentication configuration includes the following tasks:
· Enable NTP authentication
· Configure an authentication key
· Configure the key as a trusted key
· Associate the specified key with an NTP server or a symmetric peer
The above tasks are required. If any task is missed, the NTP authentication cannot function.
Configuring NTP authentication in client/server mode
When configuring NTP authentication in client/server mode, you need to configure the required tasks on both the client and server, and associate the key with the NTP server on the client.
· If NTP authentication is not enabled or no key is associated with the NTP server on the client, no NTP authentication is performed when the client synchronizes its clock to the server. No matter NTP authentication is enabled on the server or not, the clock synchronization between the server and client can be performed.
· If NTP authentication is enabled and a key is associated with the NTP server on the client, but the key is a trusted key, no matter NTP authentication is enabled on the server or not, the client does not synchronize its clock to the server.
Configuring NTP authentication for a client
To configure NTP authentication for a client:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key by default |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default |
5. Associate the specified key with an NTP server. |
ntp-service unicast-server { ip-address | server-name } authentication-keyid keyid |
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. |
|
NOTE: 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 key is trusted. |
Configuring NTP authentication for a server
To configure NTP authentication for a server:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key by default |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default |
|
NOTE: The same authentication key must be configured on both the server and client sides. |
Configuring NTP authentication in symmetric peers mode
When configuring NTP authentication in symmetric peers mode, configure the required tasks on both the active and passive peers, and on the active peer associate the key with the passive peer.
1. When the active peer has a greater stratum level than the passive peer:
¡ If NTP authentication is not enabled or no key is associated with the passive peer on the active peer, the active peer synchronizes its clock to the passive peer as long as NTP authentication is disabled on the passive peer.
¡ If NTP authentication is enabled and a key is associated with the passive peer on the active peer, but the key is not a trusted key, no matter the NTP authentication is enabled on the passive peer or not, the active peer does not synchronize its clock to the passive peer.
2. When the active peer has a smaller stratum level than the passive peer:
If NTP authentication is not enabled, no key is associated with the passive peer on the active peer, or the key is not a trusted key, the clock of the active peer can be synchronized to the passive peer as long as NTP authentication is disabled on the passive peer.
Configuring NTP authentication for an active peer
To configure NTP authentication for an active peer:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key is configured by default. |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default |
5. Associate the specified key with the passive peer. |
ntp-service unicast-peer { ip-address | peer-name } authentication-keyid keyid |
You can associate a non-existing key with a passive peer. To enable NTP authentication, you must configure the key and specify it as a trusted key after associating the key with the passive peer. |
|
NOTE: After you enable the NTP authentication feature for the active peer, make sure that you configure for the active peer an authentication key that is the same as on the passive peer and specify that the authentication key is trusted. |
Configuring NTP authentication for a passive peer
To configure NTP authentication for a passive peer:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key is configured by default. |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default |
|
NOTE: The same authentication key must be configured on both the active and passive peers. |
Configuring NTP authentication in broadcast mode
When configuring NTP authentication in broadcast mode, configure the required tasks on both the broadcast client and broadcast server, and associate the key with the broadcast server on the server.
· If NTP authentication is not enabled, no key is associated with the broadcast server, or the key is not a trusted key, the clock of the broadcast server can be synchronized to the broadcast client as long as NTP authentication is disabled on the client.
· If NTP authentication is enabled and a key is associated with the broadcast server, and the key is a trusted key, the clock of the broadcast server can be synchronized to the broadcast client as long as NTP authentication is enabled on the client.
Configuring NTP authentication for a broadcast client
To configure NTP authentication for a broadcast client:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key is configured by default. |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default. |
|
NOTE: After you enable the NTP authentication feature for the broadcast client, make sure that you configure for the client an authentication key that is the same as on the broadcast server and specify that the authentication key is trusted. |
Configuring NTP authentication for a broadcast server
To configure NTP authentication for a broadcast server:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key is configured by default. |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default |
5. Enter interface view. |
interface interface-type interface-number |
N/A |
6. Associate the specified key with the broadcast server. |
ntp-service broadcast-server authentication-keyid keyid |
You can associate a non-existing key with the broadcast server. To enable NTP authentication, you must configure the key and specify it as a trusted key after associating the key with the broadcast server. |
|
NOTE: The same authentication key must be configured on both the broadcast server and broadcast client sides. |
Configuring NTP authentication in multicast mode
When configuring NTP authentication in multicast mode, configure the required tasks on both the multicast client and multicast server, and associate the key with the multicast server on the server.
· If the NTP authentication is not enabled, no key is associated with the multicast server on the multicast server, or the key is not a trusted key, the clock of the multicast server can be synchronized to the multicast client as long as NTP authentication is disabled on the client.
· If the NTP authentication is enabled, a key is associated with the multicast server on the multicast server, and the key is a trusted key, the clock of the multicast server can be synchronized to the multicast client as long as NTP authentication is enabled on the client.
Configuring NTP authentication for a multicast client
To configure NTP authentication for a multicast client:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key is configured by default. |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default. |
|
NOTE: After you enable the NTP authentication feature for the multicast client, make sure that you configure for the client an authentication key that is the same as on the multicast server and specify that the authentication key is trusted. |
Configuring NTP authentication for a multicast server
To configure NTP authentication for a multicast server:
Step |
Command |
Remarks |
1. Enter system view. |
system-view |
N/A |
2. Enable NTP authentication. |
ntp-service authentication enable |
Disabled by default |
3. Configure an NTP authentication key. |
ntp-service authentication-keyid keyid authentication-mode md5 value |
No NTP authentication key is configured by default. |
4. Configure the key as a trusted key. |
ntp-service reliable authentication-keyid keyid |
No authentication key is configured to be trusted by default. |
5. Enter interface view. |
interface interface-type interface-number |
N/A |
6. Associate the specified key with the multicast server. |
ntp-service multicast-server authentication-keyid keyid |
You can associate a non-existing key with the multicast server. To enable NTP authentication, you must configure the key and specify it as a trusted key after associating the key with the multicast server. |
|
NOTE: The same authentication key must be configured on both the multicast server and multicast client sides. |
Displaying and maintaining NTP
Task |
Command |
Remarks |
1. View the information of NTP service status. |
display ntp-service status [ | { begin | exclude | include } regular-expression ] |
Available in any view |
2. View the information of NTP sessions. |
display ntp-service sessions [ verbose ] [ | { begin | exclude | include } regular-expression ] |
Available in any view |
3. View the brief information of the NTP servers from the local router back to the primary reference source. |
display ntp-service trace [ | { begin | exclude | include } regular-expression ] |
Available in any view |
NTP configuration examples
|
NOTE: Unless otherwise specified, the examples given in this section apply to all switches and routers that support NTP. |
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 the client/server mode and Device A is to be used as the NTP server of Device B.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 7. (Details not shown)
2. Configure Device A:
# Specify the local clock as the reference source, with the stratum level of 2.
<DeviceA> system-view
[DeviceA] ntp-service refclock-master 2
3. 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)
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 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 routers:
· 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 the client mode and Device A is to be used as the NTP server of Device B.
· Device C works in the symmetric-active mode and Device B will act as peer of Device C. Device C is the symmetric-active peer while Device B is the symmetric-passive peer.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 8. (Details not shown)
2. Configure Device A:
# Specify the local clock as the reference source, with the stratum level of 2.
<DeviceA> system-view
[DeviceA] ntp-service refclock-master 2
3. 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
4. Configure Device C (after Device B is synchronized to Device A):
# Specify the local clock as the reference source, with the stratum level of 1.
<DeviceC> system-view
[DeviceC] ntp-service refclock-master 1
# Configure Device B 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. Because the stratus level of Device C is 1 while that of Device B is 3, Device B is synchronized to Device C.
# View the NTP status of Device B after clock synchronization.
[DeviceB] display ntp-service status
Clock status: synchronized
Clock stratum: 2
Reference clock ID: 3.0.1.33
Nominal frequency: 64.0000 Hz
Actual frequency: 64.0000 Hz
Clock precision: 2^7
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 B has been synchronized to Device C, and the clock stratum level of Device B is 2, while that of Device C is 1.
# View the NTP session information of Device B, which shows that an association has been set up between Device B and Device C.
[DeviceB] 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
[1234] 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
Configuring NTP broadcast mode
Network requirements
As shown in Figure 9, Router C functions as the NTP server for multiple routers on a network segment and synchronizes the time among multiple routers. More specifically:
· Router C’s local clock is to be used as a reference source, with the stratum level of 2.
· Router C works in the broadcast server mode and sends out broadcast messages from GigabitEthernet 3/1/10.
· Router D and Router A work in the broadcast client mode and receive broadcast messages through their respective GigabitEthernet 3/1/10.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 9. (Details not shown)
2. Configure Router C:
# Specify the local clock as the reference source, with the stratum level of 2.
<RouterC> system-view
[RouterC] ntp-service refclock-master 2
# Configure Router C to work in the broadcast server mode and send broadcast messages through GigabitEthernet 3/1/10.
[RouterC] interface GigabitEthernet 3/1/10
[RouterC-GigabitEthernet3/1/10] ntp-service broadcast-server
3. Configure Router A:
# Configure Router A to work in the broadcast client mode and receive broadcast messages on GigabitEthernet 3/1/10.
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/10
[RouterA-GigabitEthernet3/1/10] ntp-service broadcast-client
4. Configure Router B:
# Configure Router B to work in broadcast client mode and receive broadcast messages on GigabitEthernet 3/1/10.
<RouterB> system-view
[RouterB] interface GigabitEthernet 3/1/10
[RouterB-GigabitEthernet3/1/10] ntp-service broadcast-client
Router A and Router B get synchronized upon receiving a broadcast message from Router C.
# Take Router A as an example. View the NTP status of Router A after clock synchronization.
[RouterA] 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, Router A has been synchronized to Router C and the clock stratum level of Router A is 3, while that of Router C is 2.
# View the NTP session information of Router A, which shows that an association has been set up between Router A and Router C.
[RouterA-GigabitEthernet3/1/10] 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, Router C functions as the NTP server for multiple routers on different network segments and synchronizes the time among multiple routers. More specifically:
· Router C’s local clock is to be used as a reference source, with the stratum level of 2.
· Router C works in the multicast serve mode and sends out multicast messages from GigabitEthernet 3/1/10.
· Router D and Router A work in the multicast client mode and receive multicast messages through their respective GigabitEthernet 3/1/10.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 10. (Details not shown)
2. Configure Router C:
# Specify the local clock as the reference source, with the stratum level of 2.
<RouterC> system-view
[RouterC] ntp-service refclock-master 2
# Configure Router C to work in the multicast server mode and send multicast messages through GigabitEthernet 3/1/10.
[RouterC] interface GigabitEthernet 3/1/10
[RouterC-GigabitEthernet3/1/10] ntp-service multicast-server
3. Configure Router D:
# Configure Router D to work in the multicast client mode and receive multicast messages on GigabitEthernet 3/1/10.
<RouterD> system-view
[RouterD] interface GigabitEthernet 3/1/10
[RouterD-GigabitEthernet3/1/10] ntp-service multicast-client
Because Router D and Router C are on the same subnet, Router D can receive the multicast messages from Router C without being IGMP-enabled and can be synchronized to Router C.
# View the NTP status of Router D after clock synchronization.
[RouterD] 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, Router D has been synchronized to Router C and the clock stratum level of Router D is 3, while that of Router C is 2.
# View the NTP session information of Router D, which shows that an association has been set up between Router D and Router C.
[RouterD-GigabitEthernet 3/1/10] 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 Router B:
Because Router A and Router C are on different subnets, you must enable the multicast functions on Router B before Router A can receive multicast messages from Router C.
# Enable the IP multicast function.
<RouterB> system-view
[RouterB] multicast routing-enable
[RouterB] interface GigabitEthernet 3/1/1
[RouterB-GigabitEthernet3/1/1] igmp enable
[RouterB-GigabitEthernet3/1/1] igmp static-group 224.0.1.1
[RouterB-GigabitEthernet3/1/1] quit
[RouterB] interface GigabitEthernet 3/1/2
[RouterB-GigabitEthernet3/1/2] pim dm
5. Configure Router A:
<RouterA> system-view
[RouterA] interface GigabitEthernet 3/1/1
# Configure Router A to work in multicast client mode and receive multicast messages on GigabitEthernet 3/1/1.
[RouterA-GigabitEthernet3/1/1] ntp-service multicast-client
# View the NTP status of Router A after clock synchronization.
[RouterA-GigabitEthernet3/1/1] 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, Router A has been synchronized to Router C and the clock stratum level of Router A is 3, while that of Router C is 2.
# View the NTP session information of Router A, which shows that an association has been set up between Router A and Router C.
[RouterA-GigabitEthernet3/1/1] 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 configuration IGMP and PIM, see 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. More specifically:
· The local clock of Device A is to be configured as a reference source, with the stratum level of 2.
· Device B works in the 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 for Device A and Device B at the same time.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 11. (Details not shown)
2. Configure Device A
# Specify the local clock as the reference source, with the stratum level of 2.
<DeviceA> system-view
[DeviceA] ntp-service refclock-master 2
3. 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 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, you need to 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, Router C functions as the NTP server for multiple routers on different network segments and synchronizes the time among multiple routers. More specifically:
· Router C’s local clock is to be used as a reference source, with the stratum level of 3.
· Router C works in the broadcast server mode and sends out broadcast messages from GigabitEthernet 3/1/10.
· Router D works in the broadcast client mode and receives broadcast client through GigabitEthernet 3/1/10.
· NTP authentication is enabled on both Router C and Router D.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 12. (Details not shown)
2. Configure Router C:
# Specify the local clock as the reference source, with the stratum level of 3.
<RouterC> system-view
[RouterC] ntp-service refclock-master 3
# Configure NTP authentication
[RouterC] ntp-service authentication enable
[RouterC] ntp-service authentication-keyid 88 authentication-mode md5 123456
[RouterC] ntp-service reliable authentication-keyid 88
# Specify Router C as an NTP broadcast server, and specify an authentication key.
[RouterC] interface GigabitEthernet 3/1/10
[RouterC-GigabitEthernet3/1/10] ntp-service broadcast-server authentication-keyid 88
3. Configure Router D:
# Configure NTP authentication
<RouterD> system-view
[RouterD] ntp-service authentication enable
[RouterD] ntp-service authentication-keyid 88 authentication-mode md5 123456
[RouterD] ntp-service reliable authentication-keyid 88
# Configure Router D to work in the NTP broadcast client mode
[RouterD] interface GigabitEthernet 3/1/10
[RouterD-GigabitEthernet3/1/10] ntp-service broadcast-client
Now, Router D can receive broadcast messages through GigabitEthernet 3/1/10, and Router C can send broadcast messages through GigabitEthernet 3/1/10. Upon receiving a broadcast message from Router C, Router D synchronizes its clock with that of Router C.
# View the NTP status of Router D after clock synchronization.
[RouterD-GigabitEthernet3/1/10] 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)
As shown above, Router D has been synchronized to Router C and the clock stratum level of Router D is 4, while that of Router C is 3.
# View the NTP session information of Router D, which shows that an association has been set up between Router D and Router C.
[RouterD-GigabitEthernet3/1/10] 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
Total associations : 1
Configuring MPLS VPN time synchronization in client/server mode
Network requirements
As shown in Figure 13, two VPNs are present on PE 1 and PE 2: VPN 1 and VPN 2. CE 1 and CE 3 are routers in VPN 1. To synchronize the time between CE 1 and CE 3 in VPN 1, perform the following configurations:
· CE 1’s local clock is to be used as a reference source, with the stratum level of 1.
· CE 3 is synchronized to CE 1 in the client/server mode.
|
NOTE: At present, MPLS L3VPN time synchronization can be implemented only in the unicast mode (client/server mode or symmetric peers mode), but not in the multicast or broadcast mode. |
Device |
Interface |
IP address |
Device |
Interface |
IP address |
CE 1 |
GE4/1/1 |
10.1.1.1/24 |
PE 1 |
GE4/1/1 |
10.1.1.2/24 |
CE 2 |
GE4/1/1 |
10.2.1.1/24 |
|
GE4/1/2 |
172.1.1.1/24 |
CE 3 |
GE4/1/1 |
10.3.1.1/24 |
|
GE4/1/3 |
10.2.1.2/24 |
CE 4 |
GE4/1/1 |
10.4.1.1/24 |
PE 2 |
GE4/1/1 |
10.3.1.2/24 |
P |
GE4/1/1 |
172.1.1.2/24 |
|
GE4/1/2 |
172.2.1.2/24 |
|
GE4/1/2 |
172.2.1.1/24 |
|
GE4/1/3 |
10.4.1.2/24 |
Configuration procedure
|
NOTE: Prior to performing the following configuration, be sure you have completed MPLS VPN-related configurations and make sure of the reachability between CE 1 and PE 1, between PE 1 and PE 2, and between PE 2 and CE 3. For more information about MPLS VPN, see MPLS Configuration Guide. |
1. Set the IP address for each interface as shown in Figure 13. (Details not shown)
2. Configure CE 1:
# Specify the local clock as the reference source, with the stratum level of 1.
<CE1> system-view
[CE1] ntp-service refclock-master 1
3. Configure CE 3:
# Specify CE 1 in VPN 1 as the NTP server of CE 3.
<CE3> system-view
[CE3] ntp-service unicast-server 10.1.1.1
# View the NTP session information and status information on CE 3 a certain period of time later. The information should show that CE 3 has been synchronized to CE 1, with the clock stratum level of 2.
[CE3] display ntp-service status
Clock status: synchronized
Clock stratum: 2
Reference clock ID: 10.1.1.1
Nominal frequency: 63.9100 Hz
Actual frequency: 63.9100 Hz
Clock precision: 2^7
Clock offset: 0.0000 ms
Root delay: 47.00 ms
Root dispersion: 0.18 ms
Peer dispersion: 34.29 ms
Reference time: 02:36:23.119 UTC Jan 1 2001(BDFA6BA7.1E76C8B4)
[CE2] display ntp-service sessions
source reference stra reach poll now offset delay disper
**************************************************************************
[12345]10.1.1.1 LOCL 1 7 64 15 0.0 47.0 7.8
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations : 1
[CE3] display ntp-service trace
server 127.0.0.1,stratum 2, offset -0.013500, synch distance 0.03154
server 10.1.1.1,stratum 1, offset -0.506500, synch distance 0.03429
refid 127.127.1.0
Configuring MPLS VPN time synchronization in symmetric peers mode
Network requirements
As shown in Figure 13, two VPNs are present on PE 1 and PE 2: VPN 1 and VPN 2. To synchronize the time between PE 1 and PE 2 in VPN 1, perform the following configurations:
· PE 1’s local clock is to be used as a reference source, with the stratum level of 1.
· PE 2 is synchronized to PE 1 in the symmetric peers mode, and specify that the VPN is VPN 1.
Configuration procedure
1. Set the IP address for each interface as shown in Figure 13. (Details not shown)
2. Configure PE 1:
# Specify the local clock as the reference source, with the stratum level of 1.
<PE1> system-view
[PE1] ntp-service refclock-master 1
3. Configure PE 2:
# Specify PE 1 in VPN 1 as the symmetric-passive peer of PE 2.
<PE2> system-view
[PE2] ntp-service unicast-peer vpn-instance vpn1 10.1.1.2
# View the NTP session information and status information on PE 2 a certain period of time later. The information should show that PE 2 has been synchronized to PE 1, with the clock stratum level of 2.
[PE2] display ntp-service status
Clock status: synchronized
Clock stratum: 2
Reference clock ID: 10.1.1.2
Nominal frequency: 63.9100 Hz
Actual frequency: 63.9100 Hz
Clock precision: 2^7
Clock offset: 0.0000 ms
Root delay: 32.00 ms
Root dispersion: 0.60 ms
Peer dispersion: 7.81 ms
Reference time: 02:44:01.200 UTC Jan 1 2001(BDFA6D71.33333333)
[PE2] display ntp-service sessions
source reference stra reach poll now offset delay disper
**************************************************************************
[12345]10.1.1.2 LOCL 1 1 64 29 -12.0 32.0 15.6
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations : 1
[PE2] display ntp-service trace
server 127.0.0.1,stratum 2, offset -0.012000, synch distance 0.02448
server 10.1.1.2,stratum 1, offset 0.003500, synch distance 0.00781
refid 127.127.1.0