SUSE Support

Here When You Need Us

NTP time sources cannot be reached

This document (000019833) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11

Situation

This article covers the modern chronyd implementation as well as the now deprecated ntpd implementation of NTP daemons on SLES systems.

An NTP time source cannot be reached by the daemon on the client and this causes disturbances in time synchronization for the client.

For systems using  chronyd check the sources using this command:
# chronyc sources -v

The following table will be displayed:

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \               
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* time.mydomain.com             3  10   377    81  -5354us[-8257us] +/-  191ms
^? foo.example.com               0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 77.177.77.177                 0  10     0     -     +0ns[   +0ns] +/-    0ns
^? foob.example.com              0  10     0     -     +0ns[   +0ns] +/-    0ns
^? fooba.example.net             0  10     0     -     +0ns[   +0ns] +/-    0ns
^? 2a02:3d8:1::1:1               0   6     0     -     +0ns[   +0ns] +/-    0ns
^? foobar.example.org            0  10     0     -     +0ns[   +0ns] +/-    0ns

In this case the only server that is actually serving time is:

time.mydomain.com

Reach - a value of 337 tells us that the last 8 pollings were successful
LastRx - tells us the latest update was 81 seconds ago
^* - This tells us that this is the current time source
Poll - This value tells us the polling interval of a source as 2^n (seconds) so a source with a poll value of 10 is being polled at a frequency of once per 1024 (2^10) seconds. This is the default target polling interval.

We know that the other hosts were not reached because:
Reach is 0
The first column also conveniently tells us that with a '?'

For systems using ntpd the command that will show a similar table to the one above is:
# ntpq -p

Resolution

It will be necessary to troubleshoot the network connection to the remote NTP time source. If that time source is supposed to be reachable. The following is a rough guide:
 
Check that the server is reachable with ICMP packets

A simple
ping <host>
will do the trick
 
If it is reachable, run a packet capture of the connection to the time server that should be reachable to see if it is actually sending back any responses.

If there are no responses, investigate the network to see if there are any firewalls in the way that could be blocking packets. How to take a network trace is described in TID 000016753 - Taking a packet trace on Linux using tcpdump

Usually, the firewall has to be opened for incoming and outgoing UDP packets on port 123.

Cause

The causes for this can come from a large variety of sources related to the network.

Sometimes the SLES NTP client is not allowed to reach outside networks, but is trying to reach internet time servers or internet time pools.

Changes on to devices on the network (routers, firewalls, etc.) can prevent valid NTP traffic from reaching the time source or they can prevent responses from reaching the SLES client.

A local firewall can block the packets as well if it is not correctly configured by the administrator.

Other network changes, such as DNS changes or changes to the resolv.conf can be responsible for incorrect routing.

Additional Information

An interesting reference is the IETF's (Internet Engineering Task Force) Best Practices document:

https://tools.ietf.org/id/draft-ietf-ntp-bcp-13.html

This is a link to an outside blog article about understanding ntpq output:

https://detailed.wordpress.com/2017/10/22/understanding-ntpq-output/

Additional information can be found in the man pages:
man chronyd
man ntpd
and SUSE's product documentation

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000019833
  • Creation Date: 02-Mar-2021
  • Modified Date:02-Mar-2021
    • SUSE Enterprise Storage
    • SUSE Linux Enterprise High Availability Extension
    • SUSE Linux Enterprise Server
    • SUSE Linux Enterprise Server for SAP Applications
    • SUSE Manager Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.