NTP time sources cannot be reached
This document (000019833) is provided subject to the disclaimer at the end of this document.
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11
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 ^? 126.96.36.199 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:
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
Check that the server is reachable with ICMP packets
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.
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.
This is a link to an outside blog article about understanding ntpq output:
Additional information can be found in the man pages:
man chronyd man ntpdand SUSE's product documentation
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
For questions or concerns with the SUSE Knowledgebase please contact: email@example.com