Applies To:

Show Versions Show Versions

sol10240: Verifying NTP peer server communications
How-ToHow-To

Original Publication Date: 06/29/2009
Updated Date: 03/21/2014

Purpose

You should consider using these procedures under the following conditions:

  • You want to verify the Network Time Protocol (NTP) daemon service
  • You want to verify the BIG-IP system NTP configuration
  • You want to verify the communication between the BIG-IP system and the NTP peer server
  • You want to verify the network connectivity to the NTP peer server

Prerequisites

You must meet the following prerequisites to use these procedures:

  • You have root user access to the BIG-IP system
  • You have shell access to the BIG-IP command line and the Traffic Management Shell (tmsh)

Description

When the BIG-IP system clock is not showing the correct timezone or the date and time is not synchronized correctly, this could be caused by incorrect NTP configuration or a communication issue with a valid NTP peer server. The procedures in this article show how you may check the NTP daemon process, verify the NTP configuration, query the NTP peer server, and check the network connectivity to the NTP peer server.

When verifying the NTP peer server communication, you can use the ntpq utility. The command generates an output with the fields which are explained in the table as follows:

Field Definition

prefix to the remote
field

  • An asterisk (*) character indicates that the peer has been declared the system peer and lends its variables to the system variables.
  • A plus sign (+) indicates that the peer is a survivor and a candidate for the combining algorithm.
  • A space, x, period (.), dash (-), or hash (#) character indicates that this peer is not being used for synchronization because it either does not meet the requirements, is unreachable, or is not needed.
remote The remote field is the address of the remote peer.
refid The refid field is the Reference ID which identifies the server or reference clock with which the remote peer synchronizes, and its interpretation depends on the value of the stratum field (explained in the st definition). For stratum 0 (unspecified or invalid), the refid is an ascii value used for debugging. Example: INIT or STEP.  For stratum 1 (reference clock), the refid is an ascii value used to specify the type of external clock source. Example: NIST refers to NIST telephone modem.  For strata 2 through 15, the refid is the address of the next lower stratum server used for synchronization.
st The st field is the stratum of the remote peer. Primary servers (servers with an external reference clock such as GPS) are assigned stratum 1.  A secondary NTP server which synchronizes with a stratum 1 server is assigned stratum 2. A secondary NTP server which synchronizes with a stratum 2 server is assigned stratum 3. Stratum 16 is referred to as "MAXSTRAT," is customarily mapped to stratum value 0, and therefore indicates being unsynchronized.  Strata 17 through 255 are reserved.
t The t field is the type of peer: local, unicast, multicast, or broadcast.
when The when field is the time since the last response to a poll was received (in seconds).
poll The poll field is the polling interval (in seconds). This value starts low (example: 64) and over time, as no changes are detected, this polling value increases incrementally to the configured max polling value (example: 1024).
reach The reach field is the reachability register. The octal shift register records results of the last eight poll attempts.
delay The delay field is the current estimated delay; the transit time between these peers in milliseconds.
offset The offset field is the current estimated offset; the time difference between these peers in milliseconds.
jitter The jitter field is the current estimated dispersion; the variation in delay between these peers in milliseconds.

 

Procedures

Verifying the NTP daemon service
Verifying the BIG-IP system NTP configuration
Verifying the communication between BIG-IP system and the NTP peer server
Verifying the network connectivity to the NTP peer server

Verifying the NTP daemon service

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. Log in to the tmsh utility.
  2. To show the status of the NTP daemon, type the following command:

    show /sys service ntpd

    For version 9.x, you can use the similar command using bigstart from the command line, bigstart status ntpd
  1. Optional: If the NTP daemon service is not running, and you would like to start it, type the following command:

    start /sys service ntpd 

    For version 9.x, you can use the similar command using bigstart from the command line, bigstart start ntpd
  2. Optional: If the NTP daemon requires a restart, type the following command:

    restart /sys service ntpd 

    For version 9.x, you can use the similar command using bigstart from the command line, bigstart restart ntpd
  3. Type quit to exit tmsh.

Verifying the BIG-IP system NTP configuration

To verify the NTP configuration is configured appropriately, refer to the following articles:

  1. To manage the BIG-IP system NTP configuration using the command line, refer to one of the following articles:
  2. To manage the BIG-IP system NTP configuration using the Configuration utility, refer to SOL3122: Using the BIG-IP Configuration utility to add an NTP server.

Verifying the communication between BIG-IP system and the NTP peer server

Impact of procedure: Performing the following procedure should not have a negative impact on your system.

  1. Log in to the BIG-IP system command line.
  2. To verify the NTP peer server communication, type the following command:

     ntpq -np
  3. Observe the output with references on the fields presented in the table above.

    Example of a successful NTP peer server query

    If the local ntpd process can communicate or attempts to communicate with a declared NTP peer server, the output from the ntpq command appears similar to the following example:

    # ntpq -np
         remote           refid      st t  when poll reach  delay  offset   jitter
    ==============================================================================
    172.28.4.133    10.10.10.251      4 u   482 1024   377  0.815  -10.010   0.345


    In the previous example, the remote server information (refid, stratum, delay, offset, jitter) displays, which indicates that the servers are successfully exchanging information. The value of 377 in the reach column indicates that the server is successfully reached during each of the last eight attempts, and the value of 482 in the when column indicates that the last response was received from the remote peer 482 seconds ago, which is within the polling interval of 1024 seconds.

    Example of a failed NTP peer server query

    If the local ntpd process fails to communicate with a NTP peer server, the output from the ntpq command may appear similar to the following example:

    # ntpq -np     remote           refid      st t when poll reach   delay  offset   jitter
    ==============================================================================
    172.28.4.133     .INIT.          16 u    -   64    0    0.000   0.000  0000.00


    In this example, the remote server information (refid, stratum, delay, offset, jitter) is not available. The value .INIT. in the refid column indicates that NTP is initializing, and the server has not yet been reached. The value of 0 (zero) in the reach column indicates that the server has not been reached during any of the last eight attempts. The absence of a value in the when column indicates that no data has been received from the remote peer since the local ntpd process was started. The poll value of 64 is still at the MINPOLL value, which indicates that NTP was recently restarted.

    NTP has a MINPOLL and MAXPOLL value, which it uses to determine the optimal time between updates with the reference server. If jitter is low, and there are no changes in data received, NTP automatically incrementally increases the poll value until it reaches MAXPOLL, or 1024 seconds.

    Note
    : For an explanation of the inner workings of the octal shift register that displays in the reach column, and how to interpret the value contained therein, refer to Understanding NTP Reachability Statistics. This link takes you to a resource outside of AskF5, and it is possible that the document may be removed without our knowledge.

Verifying the network connectivity to the NTP peer server

If the system is unable to establish communication with a valid NTP peer server, you can perform the following actions:

  • Troubleshoot the network reachability of the system to the NTP peer server.
  • Ensure that no firewall rules prevent access to the NTP peer server.
  • Ensure that locally-managed time servers are functioning properly.

Supplemental Information

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)