SupportDocumentationRoutersService RoutersNetEngine 8000Configuration & CommissioningConfiguration Guide

NetEngine 8000 F8, NetEngine 8000E F8 V800R022C00SPC600 Configuration Guide

NTP Configuration

NTP Configuration

Overview of NTP

Definition

Network Time Protocol (NTP) is an application layer protocol in the TCP/IP protocol suite. It is used to synchronize clocks between a series of distributed time servers and clients.

Purpose

NTP is used to synchronize the time of all clock devices on a network. If time is not synchronized on a network, time errors may occur because devices run their own clocks. NTP synchronizes the time on all devices, enabling them to provide various applications based on consistent time.

NTP is mainly used in the following scenarios where the clocks of all network devices must be consistent:

  • Network management: Synchronized time is used as a reference when a network management system (NMS) analyzes the logs and debugging information collected from different devices.

  • Charging system: Synchronized time is required to ensure the accuracy and trustworthiness of charging information.

  • Several systems interworking on the same complex event: The systems must use the same clock for reference to ensure proper sequencing of operations.

  • Incremental backup between the backup server and client: Synchronized time ensures integrity of the backup data which can be used for production system recovery.

Understanding NTP

NTP Fundamentals

Figure 1-57 shows the NTP message exchange process.

Figure 1-57 NTP message exchange process

The NTP message exchange process is as follows:

  1. The NTP client sends an NTP request message to the NTP server. The NTP request message is timestamped as T1 when it leaves the NTP client.
  2. The NTP server receives the NTP request message and adds the timestamp T2 to this message.
  3. The NTP server sends an NTP response message to the NTP client. The NTP response message is timestamped as T3 when it leaves the NTP server.
  4. The NTP client receives the NTP response message and adds the timestamp T4 to this message.

Following this message exchange, the NTP client has four timestamps: T1, T2, T3, and T4.

An example assumes that the one-way delay of a link is Delay and the time difference between the NTP client and NTP server is Offset (the current time of the NTP server minus the time of the NTP client). The calculation formulas are as follows:

T2 - T1 = Delay + Offset

T4 - T3 = Delay - Offset

Therefore, Offset is calculated as follows: Offset = [(T2 - T1) - (T4 - T3)]/2. The NTP client adjusts its clock based on the Offset value to achieve synchronization with the NTP server.

The preceding is a brief introduction of how NTP works. Standard NTP algorithms can be used to further guarantee the precision of clock synchronization.

Network Structure of NTP

Figure 1-58 shows the network structure of NTP. An NTP synchronization subnet is a network of primary and secondary time servers, clients, and interconnecting transmission paths.

Figure 1-58 Network structure of NTP

A primary time server is directly synchronized to a primary reference source, usually a radio clock or a global positioning system (GPS). A secondary time server derives synchronization through a primary time server or other secondary time servers, and uses NTP to transmit time information to other hosts on a local area network (LAN).

In normal cases, the master and slave servers in a synchronization subnet form a hierarchical master-slave structure. In this hierarchical structure, the master server is located at the root, the secondary server is close to the leaf node, the number of layers increases, and the accuracy decreases.

If one or more primary or secondary time servers fail or the network paths between them fail, the synchronization subnet is automatically adjusted to maintain accurate and reliable time.

  • When all primary time servers being used on a synchronization subnet fail, one or more backup primary time servers continue operation.
  • When all primary time servers on the synchronization subnet fail, the secondary time servers synchronize among themselves. They drop off the synchronization subnet and free-run using the last determined time and frequency. Timekeeping errors are no greater than a few milliseconds per day if oscillators are appropriately stabilized, even in extended outage periods.

Operating Modes of NTP

Overview

Table 1-110 lists the operating modes of NTP.

Table 1-110 Operating modes of NTP

Operating Mode

Description

Usage Scenario

Client/Server mode

The client synchronizes its clock with the clock on the server.

In this mode, the server and client run at a high stratum level on the synchronization subnet. In this mode, the IP address of the server needs to be obtained in advance.

Peer mode

The symmetric active peer and symmetric passive peer can synchronize with each other. The peer with a lower stratum level (larger stratum value) is synchronized with the peer with a higher stratum level (smaller stratum value).

In this mode, the host runs at a relatively low stratum level on the synchronization subnet.

Broadcast mode

The server periodically sends clock synchronization packets to a broadcast address.

This mode applies to high-speed networks that have numerous workstations but lower requirements on synchronization accuracy. In typical scenarios, one or more time servers periodically send broadcast packets to workstations, which then determine the time based on a millisecond-level delay.

Multicast mode

The server periodically sends clock synchronization packets to a multicast address.

This mode applies to scenarios where a large number of clients are distributed on the network. In this mode, the NTP server multicasts an NTP packet to all clients, thereby lowering the number of NTP packets sent on the network.

Manycast mode

Manycast servers continuously listen for request packets that manycast clients periodically send to a multicast address in search of a server with the fewest number of hops.

This mode applies to scenarios where multiple servers are sparsely distributed on the network. Clients can discover and synchronize with the closest manycast server. This mode applies to networks where servers are not stable and clients do not need to be reconfigured if a server fails.

Client/Server Mode

Figure 1-59 shows the packet exchange process in client/server mode. The client synchronizes its clock with the clock on the server. The server provides synchronization information for the client but does not alter its own clock. In client/server mode, the server is also called a unicast server to distinguish it from the broadcast server, multicast server, and manycast server in other modes.

Figure 1-59 Client/Server mode

The packet exchange process in client/server mode is as follows:

  1. The client periodically sends packets to the server. The value of the Mode field in the packets is set to 3 (client mode). A client will not verify the reachability and stratum of the server.
  2. After receiving the request packet, the server sends a response packet in which the Mode field is set to 4 (server mode). The server fills in the required information to the response packet before sending it to the client. The server does not need to retain any status information.
  3. After receiving the response packet, the client performs the clock filter and selection procedure and then synchronizes its clock to the server that provides the optimal clock.

Peer Mode

Figure 1-60 shows the packet exchange process in peer mode.

Figure 1-60 Peer mode

The packet exchange process in peer mode is as follows:

  1. The symmetric active peer sends an NTP request packet to the symmetric passive peer, with the Mode field being 3 (client mode). The symmetric passive peer replies with an NTP response packet, in which the Mode field is set to 4 (server mode).
  2. The active peer periodically sends packets to the passive peer. The value of the Mode field in a packet is set to 1, indicating that the packet is sent by the active peer. Whether the peer is reachable and the number of layers of the peer are not considered.
  3. After receiving the request packet, the symmetric passive peer sends a response packet in which the Mode field is set to 2 (symmetric passive peer). The symmetric passive peer does not need to be configured. A host establishes a connection and sets relevant state variables only after an NTP packet is received.
  4. After the peer relationship is set up, the symmetric active and passive peers can synchronize with each other. The peer with a lower stratum level (larger stratum value) is synchronized with the peer with a higher stratum level (smaller stratum value).

Broadcast Mode

Figure 1-61 shows the packet exchange process in broadcast mode. In this mode, servers typically run high-speed broadcast media over the network. They provide synchronization information to all clients, but do not alter their own clocks.

Figure 1-61 Broadcast mode

The packet exchange process in broadcast mode is as follows:

  1. The broadcast server periodically sends clock synchronization packets to the broadcast address 255.255.255.255. The Mode field in the packets is set to 5 (broadcast mode or multicast mode), regardless of whether the client is reachable or the number of layers.
  2. The client listens for the broadcast packets sent from the server. After receiving the first broadcast packet, the client temporarily starts in client/server mode to exchange packets with the server. This allows the client to estimate the network delay.
  3. The client then enters the broadcast mode, continues to listen for the subsequent broadcast packets, and synchronizes the local clock according to the subsequent broadcast packets.

Multicast Mode

Figure 1-62 shows the packet exchange process in multicast mode. In this mode, servers typically run high-speed broadcast media over the network. They provide synchronization information to all clients, but do not alter their own clocks.

Figure 1-62 Multicast mode

The packet exchange process in multicast mode is as follows:

  1. The multicast server periodically sends clock synchronization packets to an IPv4 or IPv6 multicast address. The Mode field in the packets is set to 5 (broadcast or multicast mode).
  2. The client listens for the multicast packets sent from the server. After receiving the first multicast packet, the client temporarily starts in client/server mode to exchange packets with the server. This allows the client to estimate the network delay.
  3. The client then enters the multicast mode, continues to listen for the subsequent multicast packets, and synchronizes the local clock according to the subsequent multicast packets.

Manycast Mode

Figure 1-63 shows the packet exchange process in manycast mode. In this mode, servers provide synchronization information to all clients and do not alter their own clocks.

Figure 1-63 Manycast mode

The packet exchange process in manycast mode is as follows:

  1. The manycast client periodically sends request packets to an IPv4 or IPv6 multicast address to search for the closest manycast server (smallest TTL). The value of the Mode field is set to 3 (client mode).

    The initial TTL value of a request packet sent by the client is 1. The value increases by 1 each time a request packet is sent until either the client receives a response packet or the TTL value reaches the upper limit. Receipt of a response packet indicates that the client has found the closest manycast server. To subsequently maintain the connection with this server, the client sends a packet every time a timeout period expires. If the client does not receive a response packet when the TTL reaches the upper limit, the client stops sending request packets for a certain period of time (a timeout period). This timeout period allows all connections to be cleared. After the timeout period expires, the client repeats the preceding process.

  2. The manycast server continuously listens for packets. If server synchronization is possible, the server unicasts a response packet to the client, with the Mode field set to 4 (server mode).
  3. After receiving the response packet, the client performs the clock filter and selection procedure and then synchronizes its clock to the server that provides the optimal clock.

NTP Clock Source Selection

When multiple valid server candidates exist for the clock source selection, a client selects the most accurate and reliable server according to certain rules. NTP determines the quality of each clock source based on the following parameters:

  • Offset: indicates the maximum-likelihood time offset of the server clock relative to the system clock.
  • Delay: indicates the round-trip delay between the client and server.
  • Dispersion: indicates the maximum error inherent in the measurement.
  • Jitter: indicates the root mean square (RMS) average of the most recent offset differences.

Upon receipt of each NTP response packet, a client updates the values of these four parameters to measure the system clock relative to each server clock. The client uses the selection, cluster, and combine algorithms to determine the most accurate and reliable candidates to synchronize the system clock. The selection algorithm is used to select a list of accurate and reliable servers based on the values of the offset, delay, dispersion, and jitter parameters. The cluster algorithm uses statistical principles to find the most accurate set of truechimers (a truechimer is a clock that maintains timekeeping accuracy to a previously published and trusted standard). The combine algorithm computes the final clock offset by statistically averaging the surviving truechimers.

NTP Packet Format

Figure 1-64 shows the NTP packet format.

Figure 1-64 NTP packet format
Table 1-111 Description of each field in an NTP packet

Field

Length

Description

LI (Leap Indicator)

2 bits

A code warning of an impending leap second to be inserted or deleted in the NTP timescale. The bit values are defined as follows:

  • 00: no warning
  • 01: last minute has 61 seconds
  • 10: last minute has 59 seconds
  • 11: alarm condition (clock not synchronized)

VN (Version Number)

3 bits

NTP version number. The current version is 3.

Mode

3 bits

NTP mode.

The values are defined as follows:

  • 0: reserved
  • 1: symmetric active
  • 2: symmetric passive
  • 3: client mode
  • 4: server mode
  • 5: broadcast mode
  • 6: reserved for NTP control messages
  • 7: reserved for private use

Stratum

8 bits

Stratum level of the local clock. It defines the precision of the clock. The value of this field ranges from 1 to 15. A stratum 1 clock has the highest precision.

Poll

8 bits

Maximum interval between successive messages.

Precision

8 bits

Precision of the local clock.

Root Delay

32 bits

Total round-trip delay to the primary reference source.

Root Dispersion

32 bits

Maximum error relative to the primary reference source.

Reference Identifier

32 bits

ID of a reference clock.

Reference Timestamp

64 bits

Local time at which the local clock was last set or corrected. Value 0 indicates that the local clock is never synchronized.

Originate Timestamp

64 bits

Local time at which an NTP request packet departed the client for the server.

Receive Timestamp

64 bits

Local time at which an NTP request packet arrived at the server.

Transmit Timestamp

64 bits

Local time at which an NTP response packet departed the server for the client.

Authenticator

96 bits

(Optional) Authenticator information.

Configuration Precautions for NTP

Feature Requirements

Table 1-112 Feature requirements

Feature Requirements

Series

Models

1. The existing configuration will not be deleted when the NTP service is disabled.

2. Currently, each device can be configured with a maximum of 256 multicast servers, peers, unicast servers, 1024 NTP authentication keys, and 1024 multicast clients. A maximum of 256 multicast clients can take effect simultaneously.

3. A device running NTP supports a maximum of 256 sessions at the same time, including static and dynamic sessions.

NetEngine 8000 F8

NetEngine 8000 F8

For security purposes, you are not advised to use the weak security algorithm or weak security protocol provided by this feature. By default, the device provides the weak security algorithm or protocol feature package WEAKEA. If it is required, run the install feature-software WEAKEA command to install the weak security algorithm or protocol feature package WEAKEA.

NetEngine 8000 F8

NetEngine 8000 F8

Default Settings for NTP

Table 1-113 describes the default settings for NTP.

Table 1-113 Default settings for NTP

Parameter

Default Setting

Maximum synchronization distance

1s

NTP server

Enabled

After any NTP command is configured, the system automatically disables the NTP server function. The NTP server takes effect only after Enabling the NTP Server Function is performed.

Listening interface of the NTP server

By default, the system does not listen to any interface and therefore does not respond to any NTP client request.

Configuring Basic NTP Functions

Configuring the NTP Master Clock and Listening Interfaces

Context

An NTP master clock can be configured on the server (which can be a unicast server, broadcast server, multicast server, manycast server, or symmetric passive peer) to provide the reference time for other devices. In addition, an interface that listens for external NTP packets needs to be specified. Otherwise, the server fails to respond to client requests.

An NTP master clock does not need to be configured when the local server has been synchronized with an NTP master clock at a higher stratum. When this is the case, if the NTP master clock at a higher stratum fails, the local server cannot provide the reference time for lower-level clients. To resolve this problem, you are advised to configure an NTP master clock on the local server and set its clock stratum to that of the upper-level server plus 1.

Procedure

  1. Enter the system view.

    system-view

  2. Configure the NTP master clock.

    ntp-service refclock-master [ ip-address ] [ stratum ]

    Configure the local clock as the NTP master clock to provide the reference time for other devices. The value of stratum must be smaller than the stratum value of a client. Otherwise, the client cannot synchronize with the clock on the server.

  3. Configure a listening interface for the NTP server.

    • Configure a listening interface for an IPv4 NTP server.
      ntp-service server source-interface { interface-name |interface-type interface-number }

      By default, an NTP IPv4 server does not listen to any interface. If the ntp-service server source-interface all enable command is run, the device functions as an NTP IPv4 server and listens to all interfaces.

    • Configure a listening interface for an IPv6 NTP server.
      ntp-service ipv6 server source-address ipv6Addr [ vpn-instance vpnName ]

      By default, an NTP IPv6 server does not listen to any interface. If the ntp-service ipv6 server source-interface all enable command is run, the device functions as an NTP IPv6 server and listens to all interfaces.

  4. (Optional) Change the port number for receiving NTP messages.

    ntp-service port porNum

  5. Commit the configuration.

    commit

Follow-up Procedure

For details about how to enable the NTP authentication function, see Enabling NTP Authentication. Before configuring the working mode, ensure that the authentication function has been configured.

Configuring Time Parameters for Synchronizing the Client Clock

Context

If the server clock changes or multiple NTP servers are available, you need to set the clock synchronization parameters on the client clock. Such parameters include the interval and the maximum synchronization distance threshold for synchronizing the client clock. The client clock synchronizes with the clock source based on the configured clock synchronization parameters.

Procedure

  1. Enter the system view.

    system-view

  2. Configure a clock synchronization interval on the client.

    ntp-service sync-interval interval

    By default, the clock synchronization interval is not configured on the client. The value ranges from 180 to 600, in seconds.

  3. (Optional) Configure the maximum synchronization distance.

    ntp-service max-distance max-distance-value

    By default, the maximum NTP synchronization distance threshold is 1s.

  4. (Optional) Configure the offset threshold for clock synchronization.

    ntp-service offset-limit maxOffset

    By default, the offset threshold for clock synchronization is not configured on the client.

    If the time offset between the clock source and the client is greater than the offset threshold, the client does not synchronize with the clock source.

  5. Commit the configuration.

    commit

(Optional) Configuring the NTP Client/Server Mode

Context

When the client/server mode is used, you need to perform the following configurations on the client:

Procedure

  1. Enter the system view.

    system-view

  2. (Optional) Specify the source interface for sending NTP packets.

    ntp-service [ ipv6 ] source-interface { interface-name | interface_type interface_num } [ vpn-instance vpnName ]

    By default, no interface is specified for sending NTP packets.

  3. Specify the service mode of the NTP server.

    ntp-service unicast-server { ipv4Addr [ version number | authentication-keyid key-id | port port-number | source-interface { interface-name | interface-type interface-number } | vpn-instance vpn-instance-name | preferred | maxpoll max-number | minpoll min-number | burst | iburst | preempt ] * | ipv6 ipv6-address [ authentication-keyid key-id | port port-number | source-interface { interface-name | interface-type interface-number } | vpn-instance vpn-instance-name | preferred | maxpoll max-number | minpoll min-number | burst | iburst | preempt ] *

    The IP address of the NTP server is a host address and cannot be a broadcast address, a multicast address, or the IP address of the reference clock.

    If the source-interface parameter is specified, the configured server IP address must be the same as the IP address of the source interface. Otherwise, clock synchronization fails.

    If the source interface for sending NTP packets has been configured on the server and the source-interface parameter has been specified, the source-interface configuration is preferred.

  4. Commit the configuration.

    commit

(Optional) Configuring the NTP Peer Mode

Context

When the peer mode is used, you need to perform the following configurations on the symmetric active peer:

Procedure

  1. Enter the system view.

    system-view

  2. (Optional) Specify the source interface for sending NTP packets.

    ntp-service [ ipv6 ] source-interface { interface-name | interface_type interface_num } [ vpn-instance vpnName ]

    By default, no interface is specified for sending NTP packets.

  3. Perform any of the following steps to specify the symmetric passive peer:

    ntp-service unicast-peer { ipv4Addr [ version number | port port-number | authentication-keyid key-id | source-interface { interface-name | interface-type interface-number } | vpn-instance vpn-instance-name | preference | maxpoll max-number | minpoll min-number | preempt ] * | ipv6 ipv6Addr [ authentication-keyid key-id | port port-number | source-interface { interface-name | interface-type interface-number } | vpn-instance vpn-instance-name | preference | maxpoll max-number | minpoll min-number | preempt ] * }

    The IP address of the symmetric passive peer is a host address and cannot be a broadcast address, a multicast address, or the IP address of the reference clock.

    If the source-interface parameter is specified, the configured server IP address must be the same as the IP address of the source interface. Otherwise, clock synchronization fails.

    If the source interface for sending NTP packets has been configured on the symmetric passive peer and the source-interface parameter has been specified, the source-interface configuration is preferred.

  4. Commit the configuration.

    commit

(Optional) Configuring the NTP Broadcast Mode

Context

When the broadcast mode is used, you need to perform the following configurations on both the broadcast server and client.

Procedure

  • Configure an NTP broadcast server.
    1. Enter the system view.

      system-view

    2. Configure an NTP authentication key.

      ntp-service authentication-keyid keyId authentication-mode { md5 | hmac-sha256 | aes-128-cmac | aes-256-cmac } { password | cipher password }

      MD5 is a weak security algorithm and is not recommended. You are advised to use other security algorithms for NTP key authentication. To configure the MD5 algorithm, run the undo crypto weak-algorithm disable command to enable the weak security algorithm function first.

    3. Enter the view of the interface used for sending NTP broadcast packets.

      interface interface-type interface-number

    4. Configure the local device as the NTP broadcast server.

      ntp-service broadcast-server [ authentication-keyid key-id | version version-number | port port-number ] *

      After the configuration is complete, the local device functions as the NTP broadcast server periodically sending clock synchronization packets to the broadcast address 255.255.255.255 from a specified interface.

    5. Commit the configuration.

      commit

  • Configure an NTP broadcast client.
    1. Enter the system view.

      system-view

    2. Enter the view of the interface used for receiving NTP broadcast packets.

      interface interface-type interface-number

    3. Configure the local device as the NTP broadcast client.

      ntp-service broadcast-client

      After the configuration is complete, the local device functions as the NTP broadcast client listening for the NTP broadcast packets sent from the server and synchronizing the local clock with the server.

    4. Commit the configuration.

      commit

(Optional) Configuring the NTP Multicast Mode

Context

When the multicast mode is used, you need to perform the following configurations on both the multicast server and client.

Procedure

  • Configure an NTP multicast server.
    1. Enter the system view.

      system-view

    2. Configure an NTP authentication key.

      ntp-service authentication-keyid keyId authentication-mode { md5 | hmac-sha256 | aes-128-cmac | aes-256-cmac } { password | cipher password }

      MD5 is a weak security algorithm and is not recommended. You are advised to use other security algorithms for NTP key authentication. To configure the MD5 algorithm, run the undo crypto weak-algorithm disable command to enable the weak security algorithm function first.

    3. Enter the view of the interface used for sending NTP multicast packets.

      interface interface-type interface-number

    4. Configure the local device as the NTP multicast server.

      Run either of the following commands depending on whether the server IP address is an IPv4 or IPv6 address:

      ntp-service multicast-server [ ip-address ] [ authentication-keyid key-id | ttl ttl-number | version number | port port-number ] *
      ntp-service multicast-server ipv6 [ ipv6Addr ] [ authentication-keyid keyid | ttl ttl-number | port portNumber ] *

      After the configuration is complete, the local device functions as the NTP multicast server periodically sending clock synchronization packets to the configured destination multicast address from a specified interface.

    5. Commit the configuration.

      commit

  • Configure an NTP multicast client.
    1. Enter the system view.

      system-view

    2. Enter the view of the interface used for receiving NTP multicast packets.

      interface interface-type interface-number

    3. Configure the local device as the NTP multicast client.

      ntp-service multicast-client [ ip-address | ipv6 ipv6-address ]

      After the configuration is complete, the local device functions as the NTP multicast client listening for the NTP multicast packets sent from the server and synchronizing the local clock with the server.

    4. Commit the configuration.

      commit

(Optional) Configuring the NTP Manycast Mode

Context

When the manycast mode is used, you need to perform the following configurations on both the manycast server and client.

Procedure

  • Configure an NTP manycast server.
    1. Enter the system view.

      system-view

    2. Configure the interface used for sending NTP manycast packets.

      interface interface-type interface-number

    3. Configure the local device as the NTP manycast server.

      Run either of the following commands depending on whether the server IP address is an IPv4 or IPv6 address:

      ntp-service manycast-server [ ip-address ]
      ntp-service manycast-server ipv6 [ ipv6-address ]

    4. Commit the configuration.

      commit

  • Configure an NTP manycast client.
    1. Enter the system view.

      system-view

    2. Configure the interface used for receiving NTP manycast packets.

      interface interface-type interface-number

    3. Configure the local device as the NTP manycast client.

      Run either of the following commands depending on whether the client IP address is an IPv4 or IPv6 address:

      ntp-service manycast-client [ ip-address ] [ authentication-keyid key-id | ttl ttl-number | port port-number ] *
      ntp-service manycast-client ipv6 [ ipv6-address ] [ authentication-keyid key-id | ttl ttl-number | port port-number ] *

      After the configuration is complete, the NTP manycast client synchronizes the local clock with the server after receiving NTP manycast packets from the server.

    4. Commit the configuration.

      commit

Enabling the NTP Server Function

Context

After NTP-related commands are configured on a device, it automatically disables the NTP server function to prevent external devices from synchronizing their clocks with the device's clock. In addition, the device generates the ntp [ ipv6 ] server disable configuration in its configuration file. To use the device as an NTP server, enable the NTP server function on the device.

Procedure

  1. Enter the system view.

    system-view

  2. Enable the NTP server function.

    undo ntp-service [ ipv6 ] server disable

  3. Commit the configuration.

    commit

Verifying the Configuration

Prerequisites

All the basic NTP functions have been configured.

Procedure

  • Run the display ntp-service sessions command to check the NTP session status.
  • Run the display ntp-service status command to check the status of the NTP service.
  • Run the display ntp-service trace command to check the tracing path between the local device and the reference clock source.
  • Run the display ntp-service bd-status command to check the status of the clock system on the involved board of the local device.

Example for Configuring the NTP Peer Mode

Networking Requirements

As shown in Figure 1-65, three devices are in the LAN.

  • DeviceA sets its local clock as a stratum 2 NTP master clock.

  • DeviceB sets DeviceA as its NTP server. That is, DeviceB functions as an NTP client.

  • DeviceC sets DeviceB as its symmetric passive peer. That is, DeviceC functions as the symmetric active peer.

Figure 1-65 Configuring the NTP peer mode

In this example, interface1 represents GigabitEthernet1/0/1.


Configuration Roadmap

The configuration roadmap is as follows:

  1. Configure DeviceA as the local master clock so that DeviceB sends request packets to DeviceA for clock synchronization.

  2. Configure DeviceC and DeviceB as peers so that DeviceC sends request packets to DeviceB for clock synchronization.

Procedure

  1. Assign an IP address to each device and ensure that the devices are routable.
  2. Configure the NTP client/server mode.

    # Configure DeviceA to use its local clock as a stratum 2 NTP master clock.

    <DeviceA> system-view
[~DeviceA] ntp-service refclock-master 2
[*DeviceA] commit

    # Specify a listening interface on DeviceA.

    [~DeviceA] ntp-service server source-interface gigabitethernet 1/0/1 
[*DeviceA] commit

    # On DeviceB, configure DeviceA as the NTP server.

    <DeviceB> system-view
[~DeviceB] ntp-service unicast-server 10.0.1.31
[*DeviceB] commit

    # Specify a listening interface on DeviceB.

    [~DeviceB] ntp-service server source-interface gigabitethernet 1/0/1 
[*DeviceB] commit

  3. Configure the NTP peer mode.

    # On DeviceC, specify DeviceB as the symmetric passive peer.

    <DeviceC> system-view
[~DeviceC] ntp-service unicast-peer 10.0.1.32
[*DeviceC] commit

Verifying the Configuration

# Check the NTP status of DeviceB. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceB is 3, one stratum lower than DeviceA.

[~DeviceB] display ntp-service status
 clock status: synchronized
 clock stratum: 3
 reference clock ID: 10.0.1.31
 nominal frequency: 64.0029 Hz
 actual frequency: 64.0029 Hz
 clock precision: 2^7
 clock offset: 0.0000 ms
 root delay: 62.50 ms
 root dispersion: 0.20 ms
 peer dispersion: 7.81 ms
 reference time: 06:52:33.465 UTC Feb 7 2020(C7B7AC31.773E89A8)
 synchronization state: clock synchronized

# Check the NTP status of DeviceC. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceC is 4, one stratum lower than DeviceB.

[~DeviceC] display ntp-service status
 clock status: synchronized
 clock stratum: 4
 reference clock ID: 10.0.1.32
 nominal frequency: 64.0029 Hz
 actual frequency: 64.0029 Hz
 clock precision: 2^7
 clock offset: 0.0000 ms
 root delay: 124.98 ms
 root dispersion: 0.15 ms
 peer dispersion: 10.96 ms
 reference time: 06:55:50.784 UTC Feb 7 2020(C7B7ACF6.C8D002E2)
 synchronization state: clock synchronized

Configuration Scripts

  • DeviceA

    #
 sysname DeviceA
#
ntp-service refclock-master 2
ntp-service server source-interface GigabitEthernet1/0/1
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.31 255.255.255.0
#
return

  • DeviceB

    #
 sysname DeviceB
#
ntp-service server source-interface GigabitEthernet1/0/1
ntp-service unicast-server 10.0.1.31
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.32 255.255.255.0
#
return

  • DeviceC

    #
 sysname DeviceC
#
ntp-service unicast-peer 10.0.1.32
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.33 255.255.255.0
#
return

Example for Configuring the NTP Multicast Mode

Networking Requirements

On the network shown in Figure 1-66:

  • DeviceA and DeviceB are on the same network segment.

  • DeviceA functions as the NTP multicast server and sends NTP multicast packets through interface 1. Its local clock is a stratum 2 NTP master clock.

  • DeviceB listens for NTP multicast messages on interface 1.

Figure 1-66 Configuring the NTP multicast mode

In this example, interface1 represents GigabitEthernet1/0/1.


Configuration Roadmap

The configuration roadmap is as follows:

  1. Configure DeviceA as an NTP multicast server.

  2. Configure DeviceB as an NTP multicast client.

Procedure

  1. Assign an IP address to each device and ensure that the devices are routable.
  2. Configure an NTP multicast server.

    # Configure the local clock on DeviceA as a stratum 2 NTP master clock.

    <DeviceA> system-view
[~DeviceA] ntp-service refclock-master 2
[*DeviceA] commit

    # Specify a listening interface on DeviceA.

    [~DeviceA] ntp-service server source-interface gigabitethernet 1/0/1 
[*DeviceA] commit

    # Configure DeviceA as an NTP multicast server that sends NTP multicast packets from interface 1.

    [~DeviceA] interface gigabitethernet 1/0/1 
[~DeviceA-GigabitEthernet1/0/1] ntp-service multicast-server
[*DeviceA] quit
[*DeviceA] commit

  3. Configure DeviceB as an NTP multicast client that resides on the same network segment as the NTP multicast server.

    # Configure DeviceB as an NTP multicast client that listens for NTP multicast packets on interface 1.

    <DeviceB> system-view
[~DeviceB] interface gigabitethernet 1/0/1 
[~DeviceB-GigabitEthernet1/0/1] ntp-service multicast-client
[*DeviceB] quit
[*DeviceB] commit

Verifying the Configuration

# Check the NTP status of DeviceB. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceB is 3, one stratum lower than DeviceA.

[~DeviceB] display ntp-service status
 clock status: synchronized
 clock stratum: 3
 reference clock ID: 10.0.1.31
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 0.66 ms
 root delay: 24.47 ms
 root dispersion: 208.39 ms
 peer dispersion: 9.63 ms
 reference time: 17:03:32.022 UTC Feb 25 2020(C61734FD.800303C0)
 synchronization state: clock synchronized

Configuration Scripts

  • DeviceA

    #
 sysname DeviceA
#
ntp-service refclock-master 2
ntp-service server source-interface GigabitEthernet1/0/1
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.31 255.255.255.0
 ntp-service multicast-server
#
return

  • DeviceB

    #
 sysname DeviceB
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.32 255.255.255.0
 ntp-service multicast-client
#
return

Example for Configuring the NTP Manycast Mode

Networking Requirements

On the network shown in Figure 1-67:

  • DeviceC and DeviceD are on the same network segment, and DeviceA is on a different network segment. DeviceB is connected to the two network segments.

  • DeviceC is an NTP manycast server that sends anycast packets through interface 1. The local clock of DeviceC is a stratum 2 NTP master clock.

  • DeviceD and DeviceA function as manycast clients and send packets through their interface 1.

Figure 1-67 Configuring the NTP manycast mode

Interfaces 1 and 2 in this example represent GigabitEthernet1/0/1 and GigabitEthernet1/0/2, respectively.


Configuration Roadmap

The configuration roadmap is as follows:

  1. Configure DeviceC as an NTP manycast server.

  2. Configure DeviceA and DeviceD as NTP manycast clients.

Procedure

  1. Assign an IP address to each device and ensure that the devices are routable.
  2. Configure an NTP manycast server.

    # Configure the local clock on DeviceC as a stratum 2 NTP master clock.

    <DeviceC> system-view
[~DeviceC] undo ntp-service server disable 
[*DeviceC] ntp-service refclock-master 2
[*DeviceC] commit

    # Specify a listening interface on DeviceC.

    [~DeviceC] ntp-service server source-interface gigabitethernet 1/0/1
[*DeviceC] commit

    # Configure DeviceC as an NTP manycast server.

    [~DeviceC] interface gigabitethernet 1/0/1
[~DeviceC-GigabitEthernet1/0/1] ntp-service manycast-server
[*DeviceC] quit
[*DeviceC] commit

  3. Configure DeviceD.

    # Configure DeviceD as an NTP manycast client. DeviceD sends NTP manycast packets to the NTP manycast server through interface 1.

    <DeviceD> system-view
[~DeviceD] undo ntp-service server disable
[*DeviceD] interface gigabitethernet 1/0/1 
[*DeviceD-GigabitEthernet1/0/1] ntp-service manycast-client
[*DeviceD] quit
[*DeviceD] commit

  4. Configure DeviceA.

    # Configure DeviceA as an NTP manycast client. DeviceA sends NTP manycast packets to the NTP manycast server through interface 1.

    <DeviceA> system-view
[~DeviceA] undo ntp-service server disable
[*DeviceA] interface gigabitethernet 1/0/1
[*DeviceA-GigabitEthernet1/0/1] ntp-service manycast-client
[*DeviceA] quit
[*DeviceA] commit

Verifying the Configuration

# Check the NTP clock status of the manycast client (DeviceD is used as an example). The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceD is 3, one stratum lower than DeviceC.

[~DeviceD] display ntp-service status
 clock status: synchronized
 clock stratum: 3
 reference clock ID: 10.0.1.31
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 0.66 ms
 root delay: 24.47 ms
 root dispersion: 208.39 ms
 peer dispersion: 9.63 ms
 reference time: 17:03:32.022 UTC Feb 25 2020(C61734FD.800303C0)
 autokey crypto flags: 0x80021

Configuration Scripts

  • DeviceA

    #
 sysname DeviceA
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.1.1.11 255.255.255.0
 ntp-service manycast-client
#
return

  • DeviceB

    #
 sysname DeviceB
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.1.1.2 255.255.255.0
#
interface GigabitEthernet1/0/2
 undo shutdown
 ip address 10.0.1.2 255.255.255.0
#
return

  • DeviceC

    #
 sysname DeviceC
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.31 255.255.255.0
 ntp-service manycast-server
#
 ntp-service server source-interface GigabitEthernet1/0/1
#
return

  • DeviceD

    #
 sysname DeviceD
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.32 255.255.255.0
 ntp-service manycast-client
#
return

Configuring NTP Access Control

Fundamentals of NTP Access Control

NTP Authentication

NTP authentication can be enabled on networks requiring high security. Different keys can be used in different NTP operating modes.

When NTP authentication is enabled in an NTP operating mode, the system records the key IDs corresponding to the operating mode in use. The authentication process is as follows:

  • For packets sent by the system: The system determines whether authentication is required in an NTP operating mode. If authentication is not required, the system directly sends packets. If authentication is required, the system authenticates packets using both the key ID and an authentication algorithm before sending the packets.

  • For packets received by the system: The system determines whether authentication is required on the received packets. If authentication is required, the system authenticates the packets based on the key ID and a decryption algorithm. If authentication fails, the system discards the packets. If authentication succeeds, the system processes the received packets.

Access Authority

Access authority is a simple measure taken to protect devices. You can configure access authority on a device to protect its local clock.

NTP access control is implemented based on an access control list (ACL). NTP supports up to five levels of access authority. An ACL rule may be specified for each level of access authority. If an NTP access request matches an ACL rule, the device requesting access is given access authority corresponding to that level.

When an NTP access request reaches the local end, access authority is matched against the following access permissions in sequence. Peer has the maximum access permission.

  1. Peer: This indicates that a time request may be made and a control query may be performed on the local clock. The local clock can also be synchronized to a remote server.

  2. Server: This indicates that a time request may be made and a control query may be performed on the local clock. The local clock cannot be synchronized to a remote server.

  3. Synchronization: This indicates that time requests are made only on the local clock.

  4. Query: This indicates that control queries are performed only on the local clock.

  5. Limited: When the rate of NTP packets exceeds the upper limit, incoming NTP packets are discarded. If the Kiss-of-Death (KOD) function is enabled, a kiss code is sent.

KOD

The KOD function can be enabled on the server to perform access control. This is useful if the volume of packets received from clients may overload a server's loadbearing capabilities within a specified period. KOD is a modern access control technology implemented in NTPv4 and is used by the server to provide information, such as status reports and access control, to the client.

A KOD packet is a special type of NTP packet. In a KOD packet, the stratum field is 0. KOD packets support two types of kiss codes: DENY and RATE.

With the KOD function enabled on a server, the server sends kiss code DENY or RATE to the client based on configuration.

  • When receiving the kiss code DENY, the client terminates all connections to the server, and stops sending packets to the server.
  • When receiving the kiss code RATE, the client immediately reduces its polling interval to the server. The client will continue to reduce the interval if it receives subsequent RATE kiss codes.

After the KOD function is enabled, the corresponding ACL rule needs to be configured. When the ACL rule is configured as deny, the server sends the kiss code DENY. When the ACL rule is configured as permit and the number of NTP packets received reaches the configured upper limit, the server sends the RATE kiss code.

Enabling NTP Authentication

Context

NTP authentication can be enabled on networks requiring high security. With password authentication configured between the client and server sides, a client synchronize its clocks only with the authenticated server.

When configuring the NTP authentication function, comply with the following rules:

  • Enable NTP authentication before configuring the basic NTP functions. Otherwise, NTP authentication will not be performed.
  • Configure NTP authentication on both the client and server. Otherwise, NTP authentication does not take effect. In NTP peer mode, the client is the symmetric active peer, and the server is the symmetric passive peer.
  • Configure the same key on the client and server.

Procedure

  1. Enter the system view.

    system-view

  2. Enable NTP authentication.

    ntp-service authentication enable

  3. Configure an NTP authentication key.

    ntp-service authentication-keyid keyId authentication-mode { md5 | hmac-sha256 | aes-128-cmac | aes-256-cmac } { password | cipher password }

    MD5 is a weak security algorithm and is not recommended. You are advised to use other security algorithms for NTP key authentication. To configure the MD5 algorithm, run the undo crypto weak-algorithm disable command to enable the weak security algorithm function first.

    The system automatically verifies the strength of an entered key. Only the key that meets the strength requirements can be configured. To disable key strength check, run the ntp-service authentication-password complexity-check disable command.

    Disabling the key strength check function causes security risks. Therefore, you are advised not to run this command.

  4. Declare the authentication key to be reliable.

    ntp-service trusted authentication-keyid key-id

    • A device that attempts to synchronize its clock must declare its key as reliable.

    • When the client synchronizes to an authenticated server, the authentication key must be declared as reliable only on the client side.

  5. Commit the configuration.

    commit

Configuring NTP Access Authority

Context

When an NTP access request reaches the local end, access authority is matched against the following access permissions in sequence: peer, server, synchronization, query, and limited, and peer has the maximum access permission.

Procedure

  1. Enter the system view.

    system-view

  2. Create a basic ACL.

    • Create a basic IPv4 ACL.
      acl [ number] basic-acl-number
    • Create a basic ACL6.
      acl ipv6 [ number] basic-acl6-number

  3. Configure an ACL rule.

    • Configure a basic ACL rule.
      rule [ rule-id ] [ name rule-name ] { permit | deny } [ fragment-type fragment | source { source-ip-address { source-wildcard | 0 | src-netmask } | any } | time-range time-name | vpn-instance vpn-instance-name | logging ] *
    • Configure a basic ACL6 rule.
      rule [ rule-id ] [ name rule-name ] { permit | deny } [ fragment | source { source-ipv6-address { prefix-length | source-wildcard } | source-ipv6-address/prefix-length | any } | time-range time-name | vpn-instance vpn-instance-name | logging ] *
    Check the ACL rule configuration.
    • If a source IP address is set to permit in the ACL rule, packets originating from this address are permitted.
    • If a source IP address is set to deny in the ACL rule, packets originating from this address are denied.
    • If a source IP address does not match the ACL rule, packets originating from this address are denied.
    • If no rule exists in the ACL or the referenced ACL does not exist, packets from all source IP addresses are denied.

  4. Return to the system view.

    quit

  5. Commit the configuration.

    commit

  6. Configure NTP access authority on the local device.

    ntp-service access { peer | query | server | synchronization | limited } { { acl-number | acl-name aclname } [ ipv6 { acl6-number | acl6-name acl6name } ] | ipv6 { acl6-number | acl6-name acl6name } [ { acl-number | acl-name aclname } ] }

    Determine the device to be configured based on the site requirements. For details, see Table 1-114.

    Table 1-114 Description of the NTP access authority

    NTP Operating Mode

    Type of Restriction

    Configuration Object

    NTP client/server mode or NTP manycast mode

    Clock synchronization from the server to the client

    Client

    Clock synchronization request to be processed by the server

    Server

    NTP peer mode

    Clock synchronization between the symmetric active peer and symmetric passive peer

    Symmetric active end

    Clock synchronization request to be processed by the symmetric passive peer

    Symmetric passive end

    NTP multicast mode

    Clock synchronization between the client and server

    NTP multicast client

    NTP broadcast mode

    Clock synchronization between the client and server

    NTP broadcast client

  7. Commit the configuration.

    commit

Configuring KOD on the Server

Context

KOD cannot be used in broadcast or multicast mode.

Procedure

  1. Enter the system view.

    system-view

  2. Enable KOD.

    ntp-service kod-enable

  3. (Optional) Configure access control authority.

    ntp-service access { peer | query | server | synchronization | limited } { { acl-number | acl-name aclname } [ ipv6 { acl6-number | acl6-name acl6name } ] | ipv6 { acl6-number | acl6-name acl6name } [ { acl-number | acl-name aclname } ] }

  4. (Optional) Configure the minimum and average intervals for receiving NTP packets.

    ntp-service discard { min-interval min-interval-val | avg-interval avg-interval-val } *

    The value is expressed in the Nth power of 2 seconds. By default, the minimum interval for sending NTP packets is 1 (2 to the power of 1s = 2s), and the average interval is 5 (2 to the power of 5s = 32s).

  5. Commit the configuration.

    commit

Disabling an Interface from Receiving NTP Packets

Context

If a host on a LAN does not need to synchronize its clock with a specified server, you can disable a specified interface from receiving NTP packets.

Procedure

  1. Enter the system view.

    system-view

  2. Enter the interface view.

    interface interface-type interface-number

  3. (Optional) Disable an interface from receiving NTP packets.

    • Disable an interface from receiving IPv4 NTP packets.
      ntp-service in-interface disable
    • Disable an interface from receiving IPv6 NTP packets.
      ntp-service ipv6 in-interface disable

  4. Commit the configuration.

    commit

Verifying the Configuration

Procedure

  • Run the display ntp-service status command to check the status of the NTP service.
  • Run the display ntp-service sessions verbose command to check the NTP session status.

Example for Configuring the NTP Client/Server Mode with Authentication

Networking Requirements

On the network shown in Figure 1-68:

  • DeviceA functions as an NTP server and its local clock functions as a stratum 2 NTP master clock.

  • DeviceB functions as an NTP client to synchronize its clock to DeviceA.

  • DeviceC and DeviceD function as NTP clients and use DeviceB as their NTP server.

  • NTP authentication needs to be enabled on all devices.

Figure 1-68 Configuring the NTP client/server mode with authentication

Interfaces 1 and 2 in this example represent GigabitEthernet1/0/1 and GigabitEthernet1/0/2, respectively.


Precautions

  • Before specifying the NTP server address and the authentication key to be sent to the NTP server, you must enable NTP authentication on an NTP client. Otherwise, clock synchronization is directly implemented without NTP authentication.
  • The authentication keys on the NTP client and server must be the same and the authentication key must be declared. Otherwise, NTP authentication will fail.
  • Enable NTP authentication on both the server and client.

Configuration Roadmap

The configuration roadmap is as follows:

  1. Configure DeviceA as an NTP server to provide the master clock.

  2. Configure DeviceB as an NTP client to synchronize its clock to DeviceA.

  3. Configure DeviceC and DeviceD as NTP clients to synchronize their clocks to DeviceB.

  4. Configure NTP authentication on DeviceA, DeviceB, DeviceC, and DeviceD.

Procedure

  1. Assign an IP address to each device and ensure that the devices are routable.
  2. On DeviceA, configure the NTP master clock, specify a listening interface, and enable NTP authentication.

    # Configure DeviceA to use its local clock as a stratum 2 NTP master clock.

    <DeviceA> system-view
[~DeviceA] ntp-service refclock-master 2
[*DeviceA] commit

    # Specify a listening interface on DeviceA.

    [~DeviceA] ntp-service server source-interface gigabitethernet 1/0/1 
[*DeviceA] commit

    # Enable NTP authentication on DeviceA and configure an authentication key.

    [~DeviceA] ntp authentication enable
[*DeviceA] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceA] commit

    The authentication keys configured on the server and the client must be the same.

  3. On DeviceB, enable NTP authentication, specify a listening interface, and specify an NTP server.

    # Enable NTP authentication on DeviceB, configure an authentication key, and declare the authentication key as reliable.

    <DeviceB> system-view
[~DeviceB] ntp-service authentication enable
[*DeviceB] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceB] ntp-service trusted authentication-keyid 42
[*DeviceB] commit

    # Specify a listening interface on DeviceB.

    [~DeviceB] ntp-service server source-interface gigabitethernet 1/0/1
[*DeviceB] commit

    # Specify DeviceA as the NTP server of DeviceB, and configure DeviceB to use the configured authentication key.

    [~DeviceB] ntp-service unicast-server 2.2.2.2 authentication-keyid 42
[*DeviceB] commit

  4. On DeviceC, enable NTP authentication and specify its NTP server.

    <DeviceC> system-view
[~DeviceC] ntp-service authentication enable
[*DeviceC] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceC] ntp-service trusted authentication-keyid 42
[*DeviceC] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
[*DeviceC] commit

  5. On DeviceD, enable NTP authentication and specify its NTP server.

    <DeviceD> system-view
[~DeviceD] ntp-service authentication enable
[*DeviceD] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceD] ntp-service trusted authentication-keyid 42
[*DeviceD] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
[*DeviceD] commit

Verifying the Configuration

# Check the NTP status of DeviceB. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceB is 3, one stratum lower than DeviceA.

[~DeviceB] display ntp-service status
 clock status: synchronized
 clock stratum: 3
 reference clock ID: 2.2.2.2
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 3.8128 ms
 root delay: 31.26 ms
 root dispersion: 74.20 ms
 peer dispersion: 34.30 ms
 reference time: 11:55:56.833 UTC Feb 2 2020(C7B15BCC.D5604189)
 synchronization state: clock synchronized

# Check the NTP status of DeviceC. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceC is 4, one stratum lower than DeviceB.

[~DeviceC] display ntp-service status
 clock status: synchronized
 clock stratum: 4
 reference clock ID: 10.0.0.1
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 3.8128 ms
 root delay: 31.26 ms
 root dispersion: 74.20 ms
 peer dispersion: 34.30 ms
 reference time: 11:55:56.833 UTC Feb 2 2020(C7B15BCC.D5604189)
 synchronization state: clock synchronized

# Check the NTP status of DeviceD. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceD is 4, one stratum lower than DeviceB.

[~DeviceD] display ntp-service status
 clock status: synchronized
 clock stratum: 4
 reference clock ID: 10.0.0.1
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 3.8128 ms
 root delay: 31.26 ms
 root dispersion: 74.20 ms
 peer dispersion: 34.30 ms
 reference time: 11:55:56.833 UTC Feb 2 2020(C7B15BCC.D5604189)
 synchronization state: clock synchronized

# Check the NTP status of DeviceA.

[~DeviceA] display ntp-service status
 clock status: synchronized
 clock stratum: 2
 reference clock ID: LOCAL(0)
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 0.0000 ms
 root delay: 0.00 ms
 root dispersion: 26.50 ms
 peer dispersion: 10.00 ms
 reference time: 12:01:48.377 UTC Feb 2 2020(C7B15D2C.60A15981)
 synchronization state: clock synchronized

Configuration Scripts

  • DeviceA

    #
 sysname DeviceA
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#JA!v6M22=Gg\{>U.lx%#)c%yY}0*"/`5mi><QS)L%+%#
ntp-service refclock-master 2
ntp-service authentication enable
ntp-service server source-interface GigabitEthernet1/0/1
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 2.2.2.2 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 2.2.2.0 0.0.0.255
#
return

  • DeviceB

    #
 sysname DeviceB
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#>hD8))_H-XZVut2u3!_0lq3,+Ph=:OE}pX;T2M'9%+%#
ntp-service trusted authentication-keyid 42
ntp-service unicast-server 2.2.2.2 authentication-keyid 42
ntp-service authentication enable
ntp-service server source-interface GigabitEthernet1/0/1
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.0.1 255.255.255.0
#
interface GigabitEthernet1/0/2
 undo shutdown
 ip address 10.1.1.11 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.1.1.0 0.0.0.255
  network 10.0.0.0 0.0.0.255
#
return

  • DeviceC

    #
 sysname DeviceC
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#m:fVJfk*r&3x"1J`21^K`Y;LH;B+g(t2<ZX^}Q_~%+%#
ntp-service trusted authentication-keyid 42
ntp-service unicast-server 10.0.0.1 authentication-keyid 42
ntp-service authentication enable
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.0.2 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.0.0.0 0.0.0.255
#
return

  • DeviceD

    #
 sysname DeviceD
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#$\`_6BKWy1]kdR@=c;O@UX!)Vor5iYi|zIYEG_v5%+%#
ntp-service trusted authentication-keyid 42
ntp-service unicast-server 10.0.0.1 authentication-keyid 42
ntp-service authentication enable
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.0.3 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.0.0.0 0.0.0.255
#
return

Example for Configuring the NTP Broadcast Mode with Authentication

Networking Requirements

On the network shown in Figure 1-69:

  • DeviceA and DeviceB are on the same network segment.

  • DeviceA functions as an NTP broadcast server and sends NTP broadcast packets through interface 1. Its local clock is a stratum 3 NTP master clock.

  • DeviceB listens for NTP broadcast messages on interface 1.

  • NTP authentication needs to be enabled on DeviceA and DeviceB.

Figure 1-69 Configuring the NTP broadcast mode with authentication

In this example, interface1 represents GigabitEthernet1/0/1.


Precautions

Before configuring an authentication key on the client or server, ensure that the key already exists.

Configuration Roadmap

The configuration roadmap is as follows:

  1. Configure DeviceA as an NTP broadcast server.

  2. Configure DeviceB as an NTP broadcast client.

  3. Enable NTP authentication on DeviceA and DeviceB.

Procedure

  1. Assign an IP address to each device and ensure that the devices are routable.
  2. Configure DeviceA as an NTP broadcast server.

    # Configure the local clock on DeviceA as a stratum 3 NTP master clock.

    <DeviceA> system-view
[~DeviceA] ntp-service refclock-master 3
[*DeviceA] commit

    # Specify a listening interface on DeviceA.

    [~DeviceA] ntp-service server source-interface gigabitethernet 1/0/1 
[*DeviceA] commit

    # Enable NTP authentication.

    [~DeviceA] ntp-service authentication enable
[*DeviceA] ntp-service authentication-keyid 16 authentication-mode hmac-sha256 ********
[*DeviceA] commit

    # Configure DeviceA as an NTP broadcast server that sends NTP broadcast packets from interface 1, and configure an authentication key with key ID being 16.

    [~DeviceA] interface gigabitethernet 1/0/1
[~DeviceA-GigabitEthernet1/0/1] ntp-service broadcast-server authentication-keyid 16
[*DeviceA-GigabitEthernet1/0/1] quit
[*DeviceA] commit

  3. Configure DeviceB as an NTP broadcast client that resides on the same network segment as the NTP broadcast server.

    # Enable NTP authentication.

    <DeviceB> system-view
[~DeviceB] ntp-service authentication enable
[*DeviceB] ntp-service authentication-keyid 16 authentication-mode hmac-sha256 ********
[*DeviceB] ntp-service trusted authentication-keyid 16
[*DeviceB] commit

    # Configure DeviceB as an NTP broadcast client that listens for NTP broadcast packets on interface 1.

    [~DeviceB] interface gigabitethernet 1/0/1
[*DeviceB-GigabitEthernet1/0/1] ntp-service broadcast-client
[*DeviceB-GigabitEthernet1/0/1] quit
[*DeviceB] commit

Verifying the Configuration

# Check the NTP status of DeviceB. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceB is 4, one stratum lower than DeviceA.

[~DeviceB] display ntp-service status
 clock status: synchronized
 clock stratum: 4
 reference clock ID: 10.0.1.31
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 0.0000 ms
 root delay: 0.00 ms
 root dispersion: 0.42 ms
 peer dispersion: 0.00 ms
 reference time: 12:17:21.773 UTC Feb 7 2020(C7B7F851.C5EAF25B)
 synchronization state: clock synchronized

Configuration Scripts

  • DeviceA

    #
 sysname DeviceA
#
ntp-service authentication-keyid 16 authentication-mode hmac-sha256 cipher %+%#>hD8))_H-XZVut2u3!_0lq3,+Ph=:OE}pX;T2M'9%+%#
ntp-service refclock-master 3
ntp-service authentication enable
ntp-service server source-interface GigabitEthernet1/0/1
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.31 255.255.255.0
 ntp-service broadcast-server authentication-keyid 16
#
return

  • DeviceB

    #
 sysname DeviceB
#
ntp-service authentication-keyid 16 authentication-mode hmac-sha256 cipher %+%#m:fVJfk*r&3x"1J`21^K`Y;LH;B+g(t2<ZX^}Q_~%+%#
ntp-service trusted authentication-keyid 16
ntp-service authentication enable
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.1.32 255.255.255.0
 ntp-service broadcast-client
#
return

Example for Configuring KOD Authentication in Client/Server Mode

Networking Requirements

On the network shown in Figure 1-70:

  • DeviceA functions as an NTP unicast server, and its local clock functions as a stratum 2 NTP master clock.

  • DeviceB functions as an NTP unicast client that synchronizes its clock to DeviceA.

  • DeviceC and DeviceD function as NTP clients and use DeviceB as their NTP server.

  • NTP authentication is enabled.

  • KOD is enabled on DeviceA so that DeviceA can perform access control when the volume of packets received overloads its loadbearing capabilities.
Figure 1-70 Configuring KOD authentication in client/server mode

Interfaces 1 and 2 in this example represent GigabitEthernet1/0/1 and GigabitEthernet1/0/2, respectively.


Precautions

  • Before configuring a key on the client or server, ensure that the key already exists.
  • The authentication key must be reliable on both the client and server. Authentication must be enabled on the client.

Configuration Roadmap

The configuration roadmap is as follows:

  1. Configure DeviceA as an NTP server to provide the master clock.

  2. Configure DeviceB as an NTP client to synchronize its clock to DeviceA.

  3. Configure DeviceC and DeviceD as NTP clients to synchronize their clocks to DeviceB.

  4. Enable NTP authentication on all devices.

  • Before specifying the NTP server address and the authentication key to be sent to the NTP server, you must enable NTP authentication on an NTP client. Otherwise, clock synchronization is directly implemented without NTP authentication.

  • You must completely configure the client and server to ensure successful authentication.

Procedure

  1. Assign an IP address to each device and ensure that the devices are routable.
  2. On DeviceA, configure the NTP master clock, specify a listening interface, and enable NTP authentication.

    # Configure the local clock on DeviceA as a stratum 2 NTP master clock.

    <DeviceA> system-view
[~DeviceA] ntp-service refclock-master 2
[*DeviceA] commit

    # Specify a listening interface on DeviceA.

    [~DeviceA] ntp-service server source-interface gigabitethernet 1/0/1
[*DeviceA] commit

    # Enable NTP authentication and configure an authentication key. The authentication key configured on the client must be the same as that on the server.

    [~DeviceA] ntp-service authentication enable
[*DeviceA] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceA] commit

    # Configure an ACL rule.

    [~DeviceA] acl 2000
[*DeviceA-acl4-basic-2000] rule 2000 permit source 10.1.1.11 0
[*DeviceA-acl4-basic-2000] quit
[*DeviceA] commit

    # Configure access control.

    [~DeviceA] ntp-service access limited 2000
[*DeviceA] commit

    # Configure the minimum and average intervals for receiving NTP packets.

    [~DeviceA] ntp-service discard min-interval 4 avg-interval 4
[*DeviceA] commit

    # Enable KOD.

    [~DeviceA] ntp-service kod-enable
[*DeviceA] commit

  3. On DeviceB, configure the NTP master clock, specify a listening interface, and enable NTP authentication.

    # Enable NTP authentication on DeviceB, configure an authentication key, and declare the authentication key as reliable.

    <DeviceB> system-view
[~DeviceB] ntp-service authentication enable
[*DeviceB] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceB] ntp-service trusted authentication-keyid 42
[*DeviceB] commit

    # Specify a listening interface on DeviceB.

    [~DeviceB] ntp-service server source-interface gigabitethernet 1/0/1
[*DeviceB] commit

    # Specify DeviceA as the NTP server of DeviceB, and configure DeviceB to use the configured authentication key.

    [~DeviceB] ntp-service unicast-server 2.2.2.2 authentication-keyid 42
[*DeviceB] commit

  4. Specify DeviceB as the NTP server of DeviceC.

    <DeviceC> system-view
[~DeviceC] ntp-service authentication enable
[*DeviceC] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceC] ntp-service trusted authentication-keyid 42
[*DeviceC] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
[*DeviceC] commit

  5. Specify DeviceB as the NTP server of DeviceD.

    <DeviceD> system-view
[~DeviceD] ntp-service authentication enable
[*DeviceD] ntp-service authentication-keyid 42 authentication-mode hmac-sha256 ********
[*DeviceD] ntp-service trusted authentication-keyid 42
[*DeviceD] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
[*DeviceD] commit

Verifying the Configuration

# Check the NTP status of DeviceB. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceB is 3, one stratum lower than DeviceA.

[~DeviceB] display ntp-service status
 clock status: synchronized
 clock stratum: 3
 reference clock ID: 2.2.2.2
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 3.8128 ms
 root delay: 31.26 ms
 root dispersion: 74.20 ms
 peer dispersion: 34.30 ms
 reference time: 11:55:56.833 UTC Feb 2 2020(C7B15BCC.D5604189)
 synchronization state: spike (clock will be set in 1010 secs)

# Check the NTP status of DeviceC. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceC is 4, one stratum lower than DeviceB.

[~DeviceC] display ntp-service status
 clock status: synchronized
 clock stratum: 4
 reference clock ID: 10.0.0.1
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 3.8128 ms
 root delay: 31.26 ms
 root dispersion: 74.20 ms
 peer dispersion: 34.30 ms
 reference time: 11:55:56.833 UTC Feb 2 2020(C7B15BCC.D5604189)
 synchronization state: spike (clock will be set in 1010 secs)

# Check the NTP status of DeviceD. The command output shows that the clock status is synchronized, indicating that clock synchronization is complete. The stratum of DeviceD is 4, one stratum lower than DeviceB.

[~DeviceD] display ntp-service status
 clock status: synchronized
 clock stratum: 4
 reference clock ID: 10.0.0.1
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 3.8128 ms
 root delay: 31.26 ms
 root dispersion: 74.20 ms
 peer dispersion: 34.30 ms
 reference time: 11:55:56.833 UTC Feb 2 2020(C7B15BCC.D5604189)
 synchronization state: spike (clock will be set in 1010 secs)

# Check the NTP status of DeviceA.

[~DeviceA] display ntp-service status
 clock status: synchronized
 clock stratum: 2
 reference clock ID: LOCAL(0)
 nominal frequency: 60.0002 Hz
 actual frequency: 60.0002 Hz
 clock precision: 2^18
 clock offset: 0.0000 ms
 root delay: 0.00 ms
 root dispersion: 26.50 ms
 peer dispersion: 10.00 ms
 reference time: 12:01:48.377 UTC Feb 2 2020(C7B15D2C.60A15981)
 synchronization state: spike (clock will be set in 1010 secs)

Configuration Scripts

  • DeviceA

    #
 sysname DeviceA
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 2.2.2.2 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 2.2.2.0 0.0.0.255
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#JA!v6M22=Gg\{>U.lx%#)c%yY}0*"/`5mi><QS)L%+%#
ntp-service refclock-master 2
ntp-service access limited 2000
ntp-service authentication enable
ntp-service kod-enable
ntp-service discard min-interval 4 avg-interval 4
ntp-service server source-interface GigabitEthernet1/0/1
#
acl 2000
 rule 2000 permit source 10.1.1.11 0
#
return

  • DeviceB

    #
 sysname DeviceB
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.0.1 255.255.255.0
#
interface GigabitEthernet1/0/2
 undo shutdown
 ip address 10.0.1.1 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.0.1.0 0.0.0.255
  network 10.0.0.0 0.0.0.255
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#>hD8))_H-XZVut2u3!_0lq3,+Ph=:OE}pX;T2M'9%+%#
ntp-service trusted authentication-keyid 42
ntp-service unicast-server 2.2.2.2 authentication-keyid 42
ntp-service authentication enable
ntp-service server source-interface GigabitEthernet1/0/1
#
return

  • DeviceC

    #
 sysname DeviceC
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.0.2 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.0.0.0 0.0.0.255
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#m:fVJfk*r&3x"1J`21^K`Y;LH;B+g(t2<ZX^}Q_~%+%#
ntp-service trusted authentication-keyid 42
ntp-service authentication enable
ntp-service unicast-server 10.0.0.1 authentication-keyid 42
#
return

  • DeviceD

    #
 sysname DeviceD
#
interface GigabitEthernet1/0/1
 undo shutdown
 ip address 10.0.0.3 255.255.255.0
#
ospf 1
 area 0.0.0.0
  network 10.0.0.0 0.0.0.255
#
ntp-service authentication-keyid 42 authentication-mode hmac-sha256 cipher %+%#$\`_6BKWy1]kdR@=c;O@UX!)Vor5iYi|zIYEG_v5%+%#
ntp-service trusted authentication-keyid 42
ntp-service authentication enable
ntp-service unicast-server 10.0.0.1 authentication-keyid 42
#
return

Maintaining NTP

Monitoring the NTP Operating Status

During routing maintenance, you can run the following commands in any view to monitor the NTP operating status.

Table 1-115 Monitoring the NTP operating status

Operation

Command

Check the status of dynamic sessions maintained by the NTP service.

display ntp-service sessions [ verbose ]

Check the status of the NTP service.

display ntp-service status

Check the tracing path from the local device to the reference IPv4 clock source.

display ntp-service trace

Check the system time.

display clock

Clearing NTP Statistics

During routine maintenance, you can run the following commands in the user view to clear NTP statistics.

NTP statistics cannot be restored after they are cleared. Exercise caution when running reset commands.

Table 1-116 Clearing NTP statistics

Operation

Command

Clear statistics about all the NTP packets sent and received on the local device.

reset ntp-service statistics packet [ ipv6 ]

Clear statistics about the NTP packets sent and received on a specified interface.

reset ntp-service statistics packet [ ipv6 ] interface { interface-name | interface-type interface-number | all }

Clear statistics about a specified peer.

reset ntp-service statistics packet peer [ [ ip-address [ vpn-instance vpn-instance-name ] ] | ipv6 [ ipv6-address [ vpn-instance vpn-instance-name ] ] ]

Troubleshooting NTP

NTP Server Fails to Respond to External Access Requests

Fault Symptom

The NTP server does not respond to external access requests. As a result, the NTP client fails to synchronize its clocks with the NTP server.

Possible Causes

  1. No listening interface is configured on the NTP server.
  2. The server IP address specified on the NTP client is not the IP address of the source interface for sending NTP packets.

Procedure

  1. Check the NTP configurations on the client and server.

    display current-configuration interface [ interface-type [ interface-number ] | interface-name ] [ include-default ]

  2. Configure a listening interface for the NTP server.

    • Configure a listening interface for an IPv4 NTP server.
      ntp-service server source-interface { interface-name |interface-type interface-number }

      By default, an NTP IPv4 server does not listen to any interface. If the ntp-service server source-interface all enable command is run, the device functions as an NTP IPv4 server and listens to all interfaces.

    • Configure a listening interface for an IPv6 NTP server.
      ntp-service ipv6 server source-address ipv6Addr [ vpn-instance vpnName ]

      By default, an NTP IPv6 server does not listen to any interface. If the ntp-service ipv6 server source-interface all enable command is run, the device functions as an NTP IPv6 server and listens to all interfaces.

  3. Commit the configuration.

    commit

  4. Reconfigure the server IP address on the NTP client.

    Reconfigure the server IP address on the NTP client based on the NTP operating mode. The server IP address must be the IP address of the source interface for sending NTP packets.

NTP Authentication Does Not Take Effect

Fault Symptom

The NTP authentication function does not take effect. Clock synchronization can be performed even when the server or client is invalid (for example, the keys on the server and client are inconsistent).

Possible Causes

NTP authentication is not configured before basic NTP functions are configured.

Procedure

  1. Clear configurations of the basic NTP functions.
  2. Enable NTP authentication.
  3. Configure basic NTP functions.