This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

NTP broken with 7.1?

I have setup Astaro 7.1 as an NTP server. With 7.011 NTP was reliable (except when running BitTorrent).

Now with 7.1, the NTP server seems to die occasionally/often and my NTP client tells me "server is insane" -- i.e. the time returned from the NTP server doesn't make sense. It seems like NTP will run for a bit and then die or go "insane".

Any tips on how to diagnose/fix the NTP server with 7.1? I've tried stopping/restarting it and rebooting.  Neither one fixes the problem.


This thread was automatically locked due to age.
  • OK.
    Regardless, the clock is right on my firewall, but my PC is fluctuating wildly between -2mins and +2mins.
    I'm guessing windows' time service is getting confused, as I don't think my PC hardware clock is nearly that bad.

    Barry
  • FWIW .. we have a bunch of Netware Servers (yes they run Groupwise SUPER STABLE we are talking UPTIME of 400 days and counting !) also a couple of VMWARE servers using SuSe 10.2 SLES as Hosts, and a couple of Windows Servers ... We have a shareware product called TARDIS (been using it since NT4) it works perfect for us, it acts as a NTP server and you set the STRATUM level =2  etc .. then because it is customisable we refer it to the ASG only, if the ASG220 has a "moment" the internal systems stay linked to the TARDIS, then it catches any minor drifts form the ASG, but ALL systems internally stay sync'ed ... we RUN NETWARE with timesync "radius of 2000 milliseconds" so Novell Nds keeps sync tight .. and have time sync on LOG we have had no drift outside this in months most offset corrections are around 30 - 40 milliseconds. Its another layer but we opted for tertiary layer to time to create a system we could monitor also TARDIS emails out if it loses time sync ... so far so good
  • I'm still having LOTS of NTP failures from my WinXP PC... I've finally got a packet capture (on the PC) of 2 failures and one success. I don't see much difference, but maybe the replies aren't quick enough on the failures? (they are all under 100ms though)

    If anyone wants to see it, let me know.

    Barry
  • Tardis is one of those gems that you find out there.  Used it for years.
  • I've always used NTPD ported to windows: http://www.meinberg.de/english/sw/ntp.htm

    Barry, let's see those packet captures.
  • Zipped PCAP file attached, captured with WireShark directly on the PC that was doing the NTP request.

    There are 3 pairs of NTP packets, all initiated by me hitting the "update now" button in WinXP.
    Only the 3rd try actually succeeded on the PC.

    The ARP packets are after all of that, but it does seem a little odd to me that there is so much ARP traffic between the PC and the firewall. (I've seen the same thing when capturing the NTP traffic before.)

    .1 is the firewall's INT interface, and .13 is the PC.

    The INT interface is a bridge, btw... bridging 2 internal networks. All the NICs in the firewall are misc. Intel Pro 100's.

    Thanks!
    NTP_Failures.zip
  • As far as running an NTP server on Windows... the PCI-CISP standards require a central NTP server on the internal network, and (I believe) it needs to be on a separate machine from the webserver, etc.

    For work, I manage a web site which is co-located at an ISP. The number of machines we have there is very limited, and those machines are all dedicated to hosting the web site. Therefore, we do not have a server which would be an ideal NTP server under PCI.

    Currently, we are using an NTP server on the other end of a VPN connection. I do not consider this ideal at all, but it seems to be reasonably compliant. It has however caused problems such as when networks were renumbered at the other end of the VPN. (no, there is no shared DNS between the two networks.)

    Anyways, one of my motivations for planning to upgrade to v7 is the NTP server, but, since it doesn't work very well...
    To be honest, I can't at the moment think of any other motivating factor other than that the VPNs are supposed to be better at automatically restarting if a key is used more than once.
    We are unable to use the IPS in v6 due to an issue with the default snort.conf, but I am unsure if that has been addressed in v7.

    Also, ISTM that the UI changes in V7 actually slow things down when managing large #'s of network definitions, etc., but I can't say for sure yet as my configuration at home is miniscule to that at work.

    We probably will upgrade to v7 this year, but I would be more enthusiastic if everything were more solid.

    Thanks,
    Barry
  • There are 3 pairs of NTP packets, all initiated by me hitting the "update now" button in WinXP.
    Only the 3rd try actually succeeded on the PC.

    One difference I see is that in the 3rd request on the return packet, the Originate Time Stamp is nearly identical to the Receive and Transmit Time Stamps. On the first two requests the Originate Time Stamp is ahead of the Receive/Transmit Time Stamps by two seconds.

    So looking at the 3rd request packet, it appears that the clock on the client had already been updated by the 2nd NTP request, judging by the Reference Clock Update Time field in the 3rd request.

    Will have to do some research on the NTP protocol, but I don't see any reason why the Windows NTP client wouldn't have synchronized each time.

    As far as running an NTP server on Windows... the PCI-CISP standards require a central NTP server on the internal network, and (I believe) it needs to be on a separate machine from the webserver, etc.

    Remember that the NTP daemon doesn't actually have to do any serving - you can use it as a client to maintain contact with your NTP servers.

    The NTP daemon is much more effective at keeping the local clock in sync because it can slowly tweak the local clock if the clock is only slightly out of sync from the upstream NTP servers. It also accounts for network jitter and delay meaning it is very effective at synchronizing to distant servers (though closer is obviously better). It can also calculate a clock drift value to determine what direction the local clock naturally drifts - then use this value to constantly slightly tweak the local clock to keep it in sync without having to resort to periodic time resets.

    This means you can still use Astaro as the NTP server, you then install the Windows NTP daemon and configure it to synchronize to Astaro. Disable Window's built in NTP synchronization since NTP will be doing it for you.
  • Hi,

    I join this tread as i notice that my Astaro clock is not correct. I set NTP server to 0.be.pool.ntp.org (as i'm in belgium) but it seems Astaro doesn't sync... And as BarryG said, I don't find any NTP log on the Astaro.

    I'm running version 7.104.
  • Acutally my configuration is, that my Domain Controllers are syncing with the astaro. I regularly see events in the eventlog:
    The time provider NtpClient cannot reach or is currently receiving invalid time data from ASG 
     

    After disable/enable the NTP Server on the Astaro my Windows 2k3 servers are syncing correctly afterwards..