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.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
