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.
Parents
  • Okay, so I killed the HTTP proxy and the SOCKS5 proxy and NTP started working again. No reboot, no nothing.

    It looks like there is a fundamental problem with the packet processing (that interferes with other functions of the Astaro server) that for me is worse in 7.1 vs. 7.011.

    Even a moderate load on Astaro will cause issues in other services. Also if the CPU spikes due to 'admin-reporter.' hogging one CPU to the tune of 90-100% then there are other problems. 

    It is like Astaro is running a denial of service attack on itself [:S]

    So the lesson here is to image the Astaro box before doing a firmware upgrade. For me, 7.1 is a downgrade.
  • Something does seem to be amiss with NTP or its interaction with the hardware clock. I have 2 older IBM 8310 PCs, one running SuSE 9 (with NTP running) and one with Astaro 7.1 (setup with an NTP source) and I have swapped the hardware between the 2 and the problem follows the Astaro. They are both setup to access the same external Internet NTP source.

    The Astaro box kept semi-locking up, the Webadmin didn't want to load, you couldn't get a console login to work, I couldn't get a PPTP connection to complete but NAT functions allowing OWA access and email was passing through. I am not using the HTTP proxy, just the SMTP proxy. When I would restart the system and look at any reports there would be a large gap in time like the system had quit logging.

    What I discovered was that the system was jumping back in time and I assume that NTP couldn't handle it. I have removed all NTP Server entries and the lockup problem is gone but last night the system jumped back 13 hours (I'm using US Eastern time if that helps solve the problem). Remember, this same hardware did not have the problem with the SuSE NTP so it has something to do with the Astaro. It may have something to do with the IBM 8310 and Astaro becvause I have other hardware that doesn not have the problem but I've tried BIOS updates with no change to the problem.

    I also know that the system doesn't lose time, I check during the day, it jumps back by hours, the min. remain correct. I can't say it always happens at night but that is when I catch it because I won't have an Executive Report in the morning and when I connect to the system I discover it is because the system time hasn't reached the end of the previous day yet.

    I hope all this deatil helps.
  • Maybe a timezone problem? How many hours is it jumping? Are you using EDT (GMT -5)?

    Barry
  • I'm having occasional NTP failures on my LAN, with ASL 7.101 as the time server.

    I noticed the clock on my PC (Win XP) was off by over 2 minutes... tried to get the time settings window to do an 'update now', and it failed (timed out).

    Fired up WireShark, and tried again, but this time it worked.

    Are there any logs on ASL for the NTP service?

    These errors are logged in the Windows Event Log:
    The time service has not been able to synchronize the system time for 49152 seconds because none of the time providers has been able to provide a usable time stamp. The system clock is unsynchronized.

    I have 45 W32TIME messages logged, 15 are successes, the other 30 are errors... this is NOT GOOD!

    Barry
  • Still getting lots of NTP errors on the WinXP clients.

    This doesn't bode well for us upgrading our firewall at work, as one of the compelling features was the NTP server (for PCI compliance).

    Barry
  • This doesn't bode well for us upgrading our firewall at work, as one of the compelling features was the NTP server (for PCI compliance).

    Barry


    got any cisco gear around in that network? you can use that as ntp server...
  • Nope, not at our CoLo.

    Barry
  • Could it have something to do with the server that Astaro is syncing with?

    IMO, one major limitation of the Astaro NTP daemon is that it only lets you specify a single host to synchronize with. Any real NTP server will have at least 2 NTP servers to synchronize with and preferably 3-4.
  • Astaro is set to sync from pool.ntp.org, which is not a single host.
    I can't find an ntp log on Astaro, but the clock is correct.

    Barry
  • Astaro is set to sync from pool.ntp.org, which is not a single host.

    While pool.ntp.org is not a single host, if you are using it to synchronize your NTP server, you are only using a single host. Astaro will not let you use a DNS host group record (or other group record) as the synchronization target for the NTP server (which is the topic of one of my annoyances with V7)

    Even if the ntpd used pool.ntp.org (the hostname) instead of the first returned A record from the DNS server, ntpd also only uses the first returned A record. It does not periodically re-lookup the IP address.

    If you wanted to use pool.ntp.org as your synchronization source, you should use 0.pool.ntp.org, 1.pool.ntp.org and 2.pool.ntp.org instead which will return 3 distinct sets of IP addresses.

    Ideally, you would use one of the pools which returns servers geographically close to you since these will likely be "closer" to you on the network - the "closer" a time server is to you on the network, the more reliable that time server will be. Not to mention, more efficient since you don't have to send/receive packets half-way around the world and back.

    BTW, if Astaro is using pool.ntp.org as a default setting, they are violating the projects terms of service. Astaro should apply for a vendor specific zone.

    There is a ton of information on how to best use (and join!) pool.ntp.org on their website.
  • 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
Reply
  • 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
Children
  • 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..
  • On my side, i keep having problems with NTP on the Astaro. NTP is configure to sync with O.be.pool.ntp.org, but i have to adjust time manually quite ofen. I did it today as the astaro was 10 minuts to late... I don't understand how it's possible! 
    Or the sync doesn't work and the system clock is quite buggy, or the sync is working but the ntp.org time is not correct...

    Any idea???