On Thu, 2010-09-09 at 16:24 -0400, Richard B. Gilbert wrote:
> 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: [email protected] 
> > [mailto:[email protected]] On Behalf 
> > Of Greene, Rick
> > Sent: Wednesday, September 08, 2010 11:20 AM
> > To: [email protected]
> > 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:
> > 
> >      [r...@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:
> > 
> >       [r...@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.
> 
Virtual machines usually have their own RTC and NTP is essential for
logging system information in conjunction with NTP synchronization logs
to adhere to the policies of businesses or organizations.
> _______________________________________________
> questions mailing list
> [email protected]
> http://lists.ntp.org/listinfo/questions

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to