Table of Contents Table of Contents... 1-1 1.1 NTP Overview... 1-1 1.1.1 Applications of NTP... 1-1 1.1.2 How NTP Works... 1-2 1.1.3 NTP Message Format... 1-4 1.1.4 Operation Modes of NTP... 1-5 1.1.5 Multiple Instances of NTP... 1-8 1.2 NTP Configuration Task List... 1-9 1.3 Configuring the Operation Modes of NTP... 1-9 1.3.1 Configuring NTP Client/Server Mode... 1-10 1.3.2 Configuring the NTP Symmetric Mode... 1-11 1.3.3 Configuring NTP Broadcast Mode... 1-12 1.3.4 Configuring NTP Multicast Mode... 1-13 1.4 Configuring the Local Clock as a Reference Source... 1-14 1.5 Configuring Optional Parameters of NTP... 1-15 1.5.1 Configuring the Interface to Send NTP Messages... 1-15 1.5.2 Disabling an Interface from Receiving NTP Messages... 1-15 1.5.3 Configuring the Maximum Number of Dynamic Sessions Allowed... 1-16 1.6 Configuring Access-Control Rights... 1-16 1.6.1 Configuration Prerequisites... 1-17 1.6.2 Configuration Procedure... 1-17 1.7 Configuring NTP Authentication... 1-17 1.7.1 Configuration Prerequisites... 1-17 1.7.2 Configuration Procedure... 1-18 1.8 Displaying and Maintaining NTP... 1-20 1.9 NTP Configuration Examples... 1-20 1.9.1 Configuring NTP Client/Server Mode... 1-21 1.9.2 Configuring the NTP Symmetric Peers Mode... 1-22 1.9.3 Configuring NTP Broadcast Mode... 1-24 1.9.4 Configuring NTP Multicast Mode... 1-26 1.9.5 Configuring NTP Client/Server Mode with Authentication... 1-29 1.9.6 Configuring NTP Broadcast Mode with Authentication... 1-31 1.9.7 Configuring MPLS VPN Time Synchronization in Client/server Mode... 1-33 1.9.8 Configuring MPLS VPN Time Synchronization in Symmetric Peers Mode... 1-35 i
When configuring NTP, go to these sections for information you are interested in: NTP Overview NTP Configuration Task List Configuring the Operation Modes of NTP Configuring the Local Clock as a Reference Source Configuring Optional Parameters of NTP Configuring Access-Control Rights Configuring NTP Authentication Displaying and Maintaining NTP NTP Configuration Examples Note: The term router and the router icons used in this chapter refer to the routers in a generic sense and the switches running routing protocols. 1.1 NTP Overview Defined in RFC 1305, the network time protocol (NTP) synchronizes timekeeping among distributed time servers and clients. NTP runs over the user datagram protocol (UDP), using UDP port 123. The purpose of using NTP is to keep consistent timekeeping among all clock-dependent devices within the network so that the devices can provide diverse applications based on the consistent time. For a local system running NTP, its time can be synchronized by other reference sources and can be used as a reference source to synchronize other clocks. 1.1.1 Applications of NTP An administrator can by no means keep time synchronized 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: 1-1
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. 1.1.2 How NTP Works Figure 1-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:00am while that of Device B is set to 11:00:00am. Device B is used as the NTP time server, namely, the clock of Device A is synchronized by that of Device B. It takes 1 second for an NTP message to travel from one device to the other. 1-2
Figure 1-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:00am (T 1 ). When this NTP message arrives at Device B, it is timestamped by Device B. The timestamp is 11:00:01am (T 2 ). When the NTP message leaves Device B, Device B timestamps it. The timestamp is 11:00:02am (T 3 ). When Device A receives the NTP message, the local time of Device A is 10:00:03am (T 4 ). Up to now, Device A has sufficient information to calculate the following two important parameters: The roundtrip delay of NTP message: Delay = (T 4 T 1 ) (T 3 -T 2 ) = 2 seconds. Time difference between Device A and Device B: Offset = ((T 2 -T 1 ) + (T 3 -T 4 ))/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. 1-3
1.1.3 NTP Message Format NTP uses two types of messages, clock synchronization message and NTP control message. An NTP control message is used in environments where network management 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 1-2. 0 1 4 7 15 23 31 LI VN Mode Stratum Poll Precision Root delay (32 bits) Root dispersion (32 bits) Reference identifier (32 bits) Reference timestamp (64 bits) Originate timestamp (64 bits) Receive timestamp (64 bits) Transmit timestamp (64 bits) Authenticator (optional 96 bits) Figure 1-2 Clock synchronization message format Main fields are described as follows: LI: 2-bit leap indicator. When set to 11, it warns of an alarm condition (clock unsynchronized); when set to any other value, it is not to be processed by NTP. VN: 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 1-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: 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. 1.1.4 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. I. Client/server mode 1-5
Figure 1-3 Client/server mode In client/server mode, a client can be synchronized to a server, but not vice versa. 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 its local clock is synchronized to that of the optimal reference source. II. Symmetric peers mode Figure 1-4 Symmetric peers mode After the symmetric peers mode is configured, the symmetric active peer sends clock synchronization messages with the Mode field set to 3 (client mode) to the symmetric passive peer. The device that receives the message automatically enters the symmetric passive mode and sends a reply, with the Mode field in the message set to 4 (server mode). 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. In this case, the Mode field is set to 1 (symmetric active peer) in the clock synchronization messages sent by the symmetric active peer, and that is set to 2 (symmetric passive peer) in the response messages sent by the symmetric passive 1-6
peer. If both devices have reference clocks, the device whose local clock has a lower stratum level will synchronize the clock of the other device. III. Broadcast mode Server Client Network Periodically broadcasts clock synchronization messages (Mode 5) Clock synchronization message exchange (Mode 3 and Mode 4) After receiving the first broadcast message, the client sends a request Calculates the network delay between client and the server and enters the broadcast client mode Periodically broadcasts clock synchronization messages (Mode 5) Receives broadcast messages and synchronizes its local clock Figure 1-5 Broadcast mode In the broadcast mode, a server periodically sends clock synchronization messages to the broadcast address 255.255.255.255. Clients listen to the broadcast messages from servers. After a client receives the first broadcast message, the client initiates the client/server mode request to acquire the network delay between the client and the server. Then, the client enters the broadcast client mode and continues listening to broadcast messages, and synchronizes its local clock based on the received broadcast messages. IV. Multicast mode Server Client Network Periodically multicasts clock synchronization messages (Mode 5) Clock synchronization message exchange (Mode 3 and Mode 4) After receiving the first multicast message, the client sends a request Calculates the network delay between client and the server and enters the multicast client mode Periodically multicasts clock synchronization messages (Mode 5) Receives multicast messages and synchronizes its local clock Figure 1-6 Multicast mode In the multicast mode, a server periodically sends clock synchronization messages to the user-configured multicast address, or, if no multicast address is configured, to the default NTP multicast address 224.0.1.1. Clients listen to the multicast messages from servers. After a client receives the first multicast message, the client initiates the client/server mode request to acquire the network delay between the client and the 1-7
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 (or the symmetric passive peer) can work in the specified NTP working mode only after they exchange NTP messages with the Mode field being 3 (client mode) and the Mode field being 4 (server mode). During this message exchange process, NTP clock synchronization can be implemented. 1.1.5 Multiple Instances of NTP The client/server mode and symmetric mode support multiple instances of NTP and thus support clock synchronization within an MPLS VPN network. Namely, network devices (CEs and PEs) at different physical location can get their clocks synchronized through MPLS VPN connection, 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 instance. The NTP server on a PE can synchronize multiple NTP clients on different CEs. 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. 1-8
1.2 NTP Configuration Task List Complete these tasks to configure NTP: Task Configuring the Operation Modes of NTP Configuring the Local Clock as a Reference Source Configuring Optional Parameters of NTP Configuring Access-Control Rights Configuring NTP Authentication Remarks Optional Optional Optional Optional 1.3 Configuring the Operation Modes of NTP According to the devices position in the network and the network structure, devices can implement clock synchronization in one of the following modes: Client/server mode Symmetric peers mode Broadcast mode Multicast mode For the client/server mode or symmetric peers 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. 1-9
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 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. 1.3.1 Configuring NTP Client/Server Mode For devices working in the client/server mode, you only need to make configurations on the clients, and not on the servers. Follow these steps to configure an NTP client: To do Use the command Remarks Enter system view system-view Specify an NTP server for the device 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 ] * By default, no NTP server is specified for the device. 1-10
Note: In the ntp-service unicast-server command, ip-address must be a host address, rather than a broadcast address, a multicast address or the IP address of the local clock. When the interface sending the NTP packet is specified by the source-interface argument, the source IP address of the NTP packet will be configured as the primary IP address of the specified interface. A device can act as a server to synchronize the clock of other devices only after its clock has been synchronized. If the clock of a server has a stratum level higher than or equal to that of a client s clock, the client will not synchronize its clock to the server s. You can configure multiple servers by repeating the ntp-service unicast-server command. The clients will choose the optimal reference source. 1.3.2 Configuring the NTP Symmetric Mode For devices working in the symmetric mode, you need to specify a symmetric-passive on a symmetric-active peer. Following these steps to configure a symmetric-active device: To do Use the command Remarks Enter system view system-view Specify a symmetric-passive peer for the device 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 ] * By default, no symmetric-passive peer is specified for the device. 1-11
Note: In the symmetric 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 packets from a symmetric-active peer. In the ntp-service unicast-peer command, ip-address must be a host address, rather than a broadcast address, a multicast address or the IP address of the local clock. When the interface used to send NTP messages is specified by the source-interface argument, the source IP address of the NTP message will be configured as the primary IP address of the specified interface. 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. 1.3.3 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 mode sends a reply and synchronizes its local clock. For devices 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 commands for NTP broadcast mode can be configured only in the specific interface view. I. Configuring a broadcast client Follow these steps to configure an NTP broadcast client: To do Use the command Remarks Enter system view system-view Enter interface view Configure the device to work in the NTP broadcast client mode interface interface-type interface-number ntp-service broadcast-client Enter the interface used to receive NTP broadcast messages 1-12
II. Configuring the broadcast server Follow these steps to configure the NTP broadcast server: To do Use the command Remarks Enter system view system-view Enter interface view Configure the device to work in the NTP broadcast server mode interface interface-type interface-number ntp-service broadcast-server [ authentication-keyid keyid version number ] * Enter the interface used to send NTP broadcast messages Note: A broadcast server can synchronize broadcast clients only after its clock has been synchronized. 1.3.4 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. If using the multicast mode, you need to configure both the server and clients. The commands for the NTP multicast mode must be configured in the specific interface view. You can configure a maximum of 1,024 multicast clients, among which 128 can take effect at the same time. I. Configuring a multicast client Follow these steps to configure an NTP multicast client: To do Use the command Remarks Enter system view system-view Enter interface view Configure the device to work in the NTP multicast client mode interface interface-type interface-number ntp-service multicast-client [ ip-address ] Enter the interface used to receive NTP multicast messages The multicast IP address must be 224.0.1.1. 1-13
II. Configuring the multicast server Follow these steps to configure the NTP multicast server: To do Use the command Remarks Enter system view system-view Enter interface view Configure the device to work in the NTP multicast server mode interface interface-type interface-number ntp-service multicast-server [ ip-address ] [ authentication-keyid keyid ttl ttl-number version number ] * Enter the interface used to send NTP multicast message Note: A multicast server can synchronize broadcast clients only after its clock has been synchronized. 1.4 Configuring the Local Clock as a Reference Source A network device 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 device on the network in any of the four NTP operation modes previously described. If you configure two synchronization modes, the device will choose the optimal clock as the reference source. Follow these steps to configure the local clock as a reference source: To do Use the command Remarks Enter system view system-view Configure the local clock as a reference source ntp-service refclock-master [ ip-address ] [ stratum ] 1-14
Note: In this command, ip-address must be 127.127.1.u, where u ranges from 0 to 3, representing the NTP process ID. 1.5 Configuring Optional Parameters of NTP 1.5.1 Configuring the Interface to Send NTP Messages If you specify the interface used to send an NTP message, the device sets the source IP address of the NTP message as the primary IP address of the specified interface when sending the NTP message. 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 configure the local interface used to send NTP messages: To do Use the command Remarks Enter system view system-view Configure the interface used to send NTP messages ntp-service source-interface interface-type interface-number Caution: If you have specified an interface in the ntp-service unicast-server or ntp-service unicast-peer command, this interface will be used for sending NTP messages. If you have configured the ntp-service broadcast-server or ntp-service multicast-server command, the interface used to broadcast or multicast NTP messages is the interface configured with the respective command. 1.5.2 Disabling an Interface from Receiving NTP Messages Follow these steps to disable an interface from receiving NTP messages: To do Use the command Remarks Enter system view system-view Enter interface view interface interface-type interface-number 1-15
To do Use the command Remarks Disable the interface from receiving NTP messages ntp-service in-interface disable An interface is enabled to receive NTP messages by default. 1.5.3 Configuring the Maximum Number of Dynamic Sessions Allowed Follow these steps to configure the maximum number of dynamic sessions allowed to be established locally: 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 100 by default 1.6 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 device to perform control query to the NTP service on the local device but does not permit the peer device to synchronize its clock to the local device. The so-called control query refers to query of some states of the NTP service, including alarm information, authentication status, clock source information, and so on. synchronization: server access only. This level of right permits the peer device to synchronize its clock to the local device but does not permit the peer device to perform control query. server: server access and query permitted. This level of right permits the peer device to perform synchronization and control query to the local device but does not permit the local device to synchronize its clock to the peer device. peer: full access. This level of right permits the peer device to perform synchronization and control query to the local device and also permits the local device to synchronize its clock to the peer device. From the highest NTP service access-control right to the lowest one are peer, server, synchronization, and query. When a device receives an NTP request, it will perform an access-control right match and will use the first matched right. 1-16
1.6.1 Configuration Prerequisites Prior to configuring the NTP service access-control right to the local device, you need to create and configure an ACL associated with the access-control right. For the configuration of ACL, refer to ACL Configuration in the QoS ACL Volume. 1.6.2 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 to the local device 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. 1.7 Configuring NTP Authentication The NTP authentication feature should be enabled for a system running NTP in a network where there is a high security demand. This feature enhances the network security by means of client-server key authentication, which prohibits a client from synchronizing with a device that has failed authentication. 1.7.1 Configuration Prerequisites The configuration NTP authentication involves configuration tasks to be implemented on the client and on the server. When configuring the NTP authentication feature, pay attention to the following principles: For all synchronization modes, when you enable the NTP authentication feature, you should configure an authentication key and specify it as a trusted key. Namely, the ntp-service authentication enable command must work together with the ntp-service authentication-keyid command and the ntp-service reliable authentication-keyid command. Otherwise, the NTP authentication function cannot be normally enabled. 1-17
For the client/server mode or symmetric mode, you need to associate the specified authentication key on the client (symmetric-active peer if in the symmetric peer mode) with the corresponding NTP server (symmetric-passive peer if in the symmetric peer mode). Otherwise, the NTP authentication feature cannot be normally enabled. For the broadcast server mode or multicast server mode, you need to associate the specified authentication key on the broadcast server or multicast server with the corresponding NTP server. Otherwise, the NTP authentication feature cannot be normally enabled. For the client/server mode, if the NTP authentication feature has not been enabled for the client, the client can synchronize with the server regardless the NTP authentication feature has been enabled for the server or not. For all synchronization modes, the server side and the client side must be consistently configured. If the NTP authentication is enabled on a client, the client can be synchronized only to a server that can provide a trusted authentication key. 1.7.2 Configuration Procedure I. Configuring NTP authentication for a client Follow these steps to configure NTP authentication for a client: To do Use the command Remarks Enter system view system-view Enable NTP authentication Configure an NTP authentication key Configure the key as a trusted key ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 value ntp-service reliable authentication-keyid keyid Disabled by default No NTP authentication key by default No authentication key is configured to be trusted by default 1-18
To do Use the command Remarks Associate the specified key with an NTP server Client/server mode: ntp-service unicast-server { ip-address server-name } authentication-keyid keyid 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 you configure for the client an authentication key that is the same as on the server and specify that the authentication is trusted; otherwise, the client cannot be synchronized to the server. II. Configuring NTP authentication for a server Follow these steps to configure NTP authentication for a server: To do Use the command Remarks Enter system view system-view Enable NTP authentication Configure an NTP authentication key Configure the key as a trusted key Enter interface view ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 value ntp-service reliable authentication-keyid keyid interface interface-type interface-number Disabled by default No NTP authentication key by default No authentication key is configured to be trusted by default 1-19
To do Use the command Remarks Associate the specified key with an NTP server Broadcast server mode: ntp-service broadcast-server authentication-keyid keyid 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. 1.8 Displaying and Maintaining NTP To do Use the command Remarks View the information of NTP service status View the information of NTP sessions View the brief information of the NTP servers from the local device back to the primary reference source display ntp-service status display ntp-service sessions [ verbose ] display ntp-service trace Available in any view 1.9 NTP Configuration Examples Note: Unless otherwise specified, the examples given in this section apply to all switches and routers that support NTP. 1-20
1.9.1 Configuring NTP Client/Server Mode I. Network requirements 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. II. Network diagram Figure 1-7 Network diagram for NTP client/server mode configuration III. Configuration procedure 1) Configuration on 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 2) Configuration on 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. <DeviceB> system-view [DeviceB] ntp-service unicast-server 1.0.1.11 # (After the above configurations, Device B is synchronized to Device A.) View the NTP status of Device B after clock synchronization. [DeviceB] display ntp-service status 1-21
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 1.9.2 Configuring the NTP Symmetric Peers Mode I. Network requirements 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 peers 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. 1-22
II. Network diagram Device A 3.0.1.31/24 3.0.1.32/24 3.0.1.33/24 Device B Device C Figure 1-8 Network diagram for NTP symmetric peers mode configuration III. Configuration procedure 1) Configuration on 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 2) Configuration on Device B: # Specify Device A as the NTP server. <DeviceB> system-view [DeviceB] ntp-service unicast-server 3.0.1.31 3) Configuration on 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 the local clock 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 1-23
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 1.9.3 Configuring NTP Broadcast Mode I. Network requirements Switch C s local clock is to be used as a reference source, with the stratum level of 2. Switch C works in the broadcast server mode and sends out broadcast messages from VLAN-interface 2. Switch A and Switch D work in the broadcast client mode and listen to broadcast messages through VLAN-interface 3 and VLAN-interface 2 respectively. 1-24
II. Network diagram Vlan-int2 3.0.1.31/24 Switch C Vlan-int3 1.0.1.11/24 Vlan-int3 1.0.1.10/24 Vlan-int2 3.0.1.30/24 Switch A Switch B Vlan-int2 3.0.1.32/24 Switch D Figure 1-9 Network diagram for NTP broadcast mode configuration III. Configuration procedure 1) Configuration on Switch C: # Specify the local clock as the reference source, with the stratum level of 2. <SwitchC> system-view [SwitchC] ntp-service refclock-master 2 # Configure to send broadcast messages through VLAN-interface 2. [SwitchC] interface vlan-interface 2 [SwitchC-Vlan-interface2] ntp-service broadcast-server 2) Configuration on Switch D: # Enter system view. <SwitchD> system-view # Enter VLAN-interface 2 view. [SwitchD] interface vlan-interface 2 # Specify Switch D as the broadcast client. [SwitchD-Vlan-interface2] ntp-service broadcast-client 3) Configuration on Switch A: # Enter system view. <SwitchA> system-view # Enter VLAN-interface 3 view [SwitchA] interface vlan-interface 3 # Specify Switch A as the broadcast client. [SwitchA-Vlan-interface3] ntp-service broadcast-client 1-25
Because Switch A and Switch C are on different subnets, Switch A cannot receive the broadcast messages from Switch C Switch D gets synchronized upon receiving a broadcast message from Switch C. # View the NTP status of Switch D after clock synchronization. [SwitchD] 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 A, 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] 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 1.9.4 Configuring NTP Multicast Mode I. Network requirements Switch C s local clock is to be used as a reference source, with the stratum level of 2. Switch C works in the multicast server mode and sends out multicast messages from VLAN-interface 2. Switch A and Switch D work in the multicast client mode and listen to multicast messages through VLAN-interface 3 and VLAN-interface 2 respectively. 1-26
II. Network diagram Vlan-int2 3.0.1.31/24 Switch C Vlan-int3 1.0.1.11/24 Vlan-int3 1.0.1.10/24 Vlan-int2 3.0.1.30/24 Switch A Switch B Vlan-int2 3.0.1.32/24 Switch D Figure 1-10 Network diagram for NTP multicast mode configuration III. Configuration procedure 1) Configuration on Switch C: # Specify the local clock as the reference source, with the stratum level of 2. <SwitchC> system-view [SwitchC] ntp-service refclock-master 2 # Configure Switch C to work in the multicast server mode and send multicast messages through VLAN-interface 2. [SwitchC] interface vlan-interface 2 [SwitchC-Vlan-interface2] ntp-service multicast-server 2) Configuration on Switch D: # Configure Switch D to work in the 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 IGMP-enabled 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 1-27
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 3) Configuration on Switch B: Because Switch A and Switch C are on different subnets, you must enable IGMP 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 ethernet 4/1/3 [SwitchB-vlan3] quit [SwitchB] interface vlan-interface 3 [SwitchB-Vlan-interface3] igmp enable [SwitchB-Vlan-interface3] quit [SwitchB] interface ethernet 4/1/3 [SwitchB-Ethernet4/1/3] igmp-snooping static-group 224.0.1.1 vlan 3 4) Configuration on Switch A: # Enable IP multicast routing and IGMP. <SwitchA> system-view [SwitchA] interface vlan-interface 3 # Configure Switch A to work in the multicast client mode and receive multicast messages on VLAN-interface 3. 1-28
[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: Refer to IGMP Configuration in the IP Multicast volume for how to configure IGMP. 1.9.5 Configuring NTP Client/Server Mode with Authentication I. Network requirements 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 enabled for Device A and Device B at the same time. 1-29
II. Network diagram Figure 1-11 Network diagram for configuration of NTP client/server mode with authentication III. Configuration procedure 1) Configuration on 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 2) Configuration on Device B: <DeviceB> system-view # Enable NTP authentication on Device B. [DeviceB] ntp-service authentication enable [DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 anicekey [DeviceB] ntp-service reliable authentication-keyid 42 [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 key as a trusted key. [DeviceA] ntp-service reliable authentication-keyid 42 After the above configurations, Device B can be synchronized to Device A. # 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 1-30
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 1.9.6 Configuring NTP Broadcast Mode with Authentication I. Network requirements Switch C s local clock is to be used as a reference source, with the stratum level of 3. Switch C works in the broadcast server mode and sends out broadcast messages from VLAN-interface 2. Switch D works in the broadcast client mode and listens to broadcast messages through VLAN-interface 2. NTP authentication is enabled on both Switch C and Switch D. 1-31
II. Network diagram Vlan-int2 3.0.1.31/24 Switch C Vlan-int3 1.0.1.11/24 Vlan-int3 1.0.1.10/24 Vlan-int2 3.0.1.30/24 Switch A Switch B Vlan-int2 3.0.1.32/24 Switch D Figure 1-12 Network diagram for configuration of NTP broadcast mode with authentication III. Configuration procedure 1) Configuration on Switch C: # Specify the local clock as the reference source, with the stratum level of 3. <SwitchC> system-view [SwitchC] ntp-service refclock-master 3 # Configure NTP authentication [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 specify an authentication ID. [SwitchC] interface vlan-interface 2 [SwitchC-Vlan-interface2] ntp-service broadcast-server authentication-id 88 2) Configuration on Switch D: # Configure NTP authentication <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 [SwitchD] interface vlan-interface 2 [SwitchD-Vlan-interface2] ntp-service broadcast-client 1-32
Now, Switch D can receive broadcast messages through VLAN-interface 2, and Switch C can send broadcast messages through VLAN-interface 2. Upon receiving a broadcast message from Switch C, Switch D synchronizes its clock with that of Switch C. # View the NTP status of Switch D after clock synchronization. [SwitchD] 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, Switch D has been synchronized to Device 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] 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 1.9.7 Configuring MPLS VPN Time Synchronization in Client/server Mode I. Network requirements As shown in Figure 1-13, two VPNs are present on PE 1 and PE 2: VPN 1 and VPN 2. CE 1 and CE 2 are devices in VPN 1, while CE 3 and CE 4 are devices in VPN 2. It is required that CE 2 can be synchronized to CE 1 in the client/server mode. CE 1 is synchronized to the local reference source, with the clock stratum level being 1. 1-33
Note: At present, MPLS VPN 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. II. Network diagram VPN 1 VPN 1 CE 1 CE 2 Vlan-int20 10.1.1.1/24 Vlan-int20 10.3.1.1/24 Vlan-int20 10.1.1.2/24 Vlan-int22 10.2.1.2/24 PE 1 Vlan-int20 172.1.1.2/24 Vlan-int21 PE 2 172.2.1.1/24 Vlan-int21 Vlan-int21 172.1.1.1/24 172.2.1.2/24 MPLS backbone P Vlan-int20 10.3.1.2/24 Vlan-int22 10.4.1.2/24 Vlan-int20 10.2.1.1/24 Vlan-int20 10.4.1.1/24 CE 3 VPN 2 CE 4 VPN 2 Figure 1-13 Network diagram for MPLS VPN time synchronization configuration III. 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. Refer to the MPLS VPN Volume to configure MPLS VPN. 1) Configuration on CE 1: # Specify the local clock as the reference source, with the stratum level of 1. <CE1> system-view [CE1] ntp-service refclcok-master 1 2) Configuration on CE 2: # Specify CE 1 as the NTP server of CE 2 in VPN 1. 1-34