0

I was under the impression that the ntpd service is required to be active for my network to be getting ntp data. All of my devices are synchronized to the server's IP, yet when I SSH into the server, I cannot actually start my ntpd due to errors and it has been down for weeks.

Is there some other source besides ntpd that could be responding to all my other devices for ntp data?

Edit:

Additional info: They are all physical machines. My laptop clients are receiving NTP synchronization from my ntp server's IP, yet the ntpd has been down for weeks. I've just been running a simple ntpstat to verify synchronization. They are all RHEL 7 clients and servers.

The clients have the /etc/ntp.conf configured like so:

server 10.42.0.200 iburst 
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery 
restrict 127.0.0.1 
restrict -6 ::1

Result of ntpstat on client:

synchronized to NTP server (10.42.0.200) at stratum 7
time correct to within 31 ms
polling server every 1024 s

Result of ntpq -p on client:

    remote           refid        st t when poll reach  delay  offset  jitter
=============================================================================
*10.42.0.200      LOCAL(0)         6 u 286 1024  377   0.740   -0.520   0.392

Ntpstat on server:

synchronized to local net at stratum 6
time correct to within 11 ms
polling server every 64 s

ntpq -p:

    remote           refid        st t when poll reach  delay  offset  jitter
=============================================================================
   *LOCAL(0)           .LOCL.         5 l 14 64  377   0.000    0.000   0.000

Server ntp.conf:

server 127.127.1.0

restrict 10.42.0.0 netmask 255.255.255.0 nomodify notrap
9
  • 1
    Are they VMs or physical machines? What is the virtualization plataform? What NTP clients are the servers using? How have you configured the clients to point to that specific NTP? Please edit and add to the question. Commented Mar 5, 2019 at 14:12
  • Can you also add the output of ntpstat and ntpq -p? Commented Mar 5, 2019 at 14:17
  • Edited for the requested info. Thanks for the help.
    – Stimulai
    Commented Mar 5, 2019 at 14:28
  • 10.42.0.200 does not seem your ISP. What it is that? Commented Mar 5, 2019 at 14:28
  • It's a local server in our enclave. We had it designated as the NTP server for our enclave.
    – Stimulai
    Commented Mar 5, 2019 at 14:30

2 Answers 2

1

All the servers on your network are being synchronised with your local server 10.42.0.200.

It also seems the ntp configuration on 10.42.0.200 is being done against the local clock of the own server, and only against that. The ntp daemon wont allow other possible clients to go up if they are also installed and configured, so there should no be other sources that are talking with the NTP of your ISP.

I would cut that server 127.x line and add on it´s place the lines:

server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst

And then restart the service.

0

Your server is operating an NTP service

ntpq -p
    remote           refid        st t when poll reach  delay  offset  jitter
=============================================================================
   *LOCAL(0)           .LOCL.         5 l 14 64  377   0.000    0.000   0.000

However, it's delivering NTP from its local unsynchronised clock, which may not be what you intended. The positive net result is that all of your machines will be using the same date/time, but the downside is that you have no guarantee that it's actually correct.

It seems that this is what you - or another system administrator - have intentionally defined, since in your ntp.conf you have declared that the local clock is the time source:

server 127.127.1.0
restrict 10.42.0.0 netmask 255.255.255.0 nomodify notrap

Generally speaking, when someone does this, they are supposed to mark the server as unsynchronised so that downstream systems don't offer the time onwards. You'd do this by adding this line to your configuration

fudge  127.127.1.0 stratum 14

But even this is considered obsolete, you should really be moving towards Orphan mode, such that a group of servers can self-select the "best" time source in the event that there is no external synchronisation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .