[ntp:questions] Sync issue
Richard B. Gilbert
rgilbert88 at comcast.net
Thu Sep 9 20:24:37 UTC 2010
Greene, Rick wrote:
> Cancel this...turns out, our network team had forgot to put a route in for this subnet, as it was a new subnet of our Class B IP range.
>
> All my testing was from a different subnet of the same Class B, but of course the internet time servers are in different subnets entirely.
>
> Rick
>
> -----Original Message-----
> From: questions-bounces+rick.greene=ncogroup.com at lists.ntp.org [mailto:questions-bounces+rick.greene=ncogroup.com at lists.ntp.org] On Behalf Of Greene, Rick
> Sent: Wednesday, September 08, 2010 11:20 AM
> To: questions at lists.ntp.org
> Subject: Sync issue
>
> I'm working on setting up our own "master clock" servers for our organization to get NTP time synchronization from.
>
> The design calls for our master clock servers to get their time from several public NTP servers.
>
> I initially set this up using Fedora Core 13 running as a VMware server inside our network, and was able to get it to sync up properly:
>
> [root at coruxdev etc]# ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> +time-a.nist.gov .ACTS. 1 u 44 1024 377 13.884 2.153 7.738
> +clock.isc.org .GPS. 1 u 815 1024 377 76.939 -6.417 0.171
> *time-b.nist.gov .ACTS. 1 u 937 1024 377 12.309 0.460 4.231
>
> I then took that same config and built it on our DMZ VMware environment, and in spite of being assured that our firewall is allowing UDP 123, I can't get time sync to work:
>
> [root at extux66 ~]# ntpq -p
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> time-a.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
> clock.isc.org .INIT. 16 u - 1024 0 0.000 0.000 0.000
> time-b.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
>
> I've tried several different NTP troubleshooting documents found on the web, none have helped. I've turned off iptables that was running on the local server, that didn't make a difference.
>
> What could possibly be causing this?
>
Well, it's not rocket science! Your system is unable to get a response
from *any* of the three servers you have configured. I'm given to
understand that NTP does NOT work very well, or at all, running in a
virtual machine. Try running in the *physical* rather than the virtual
machine. The virtual machines should then be able to get their time
from the physical machine's clock.
More information about the questions
mailing list