So I made the change to 2 server, 1 in Amazon and 1 in my local office. I am seeing high
offset/drift from ntp in prometheus (alerting system). And anything to my local office
from AWS has high delay and offset. However when I check out the local office I see the
exact opposite.
[centos@freeipa03 ~]$ sudo ntpq -p remote refid st t when poll reach
delay offset
jitter============================================================================== freeipa03.east.
.INIT. 16 u - 1024 0 0.000 0.000 0.000 192.5.41.40 .INIT.
16 u - 1024 0 0.000 0.000 0.000 freeipa04.east. .INIT. 16 u
- 1024 0 0.000 0.000 0.000 192.5.41.41 .INIT. 16 u - 1024 0
0.000 0.000 0.000*freeipa01.stl1. 192.5.41.41 2 u 773 1024 377 33.174
572.967 301.884 freeipa03.stl1. LOCAL(0) 11 u 595 1024 377 32.821 -59.250
700.218 LOCAL(0) .LOCL. 10 l 5h 64 0 0.000 0.000
0.000[centos@freeipa03 ~]$ sudo ntpq -pn remote refid st t when poll
reach delay offset
jitter============================================================================== 10.10.0.31
.INIT. 16 u - 1024 0 0.000 0.000 0.000 192.5.41.40 .INIT.
16 u - 1024 0 0.000 0.000 0.000 10.10.0.32 .INIT. 16
u - 1024 0 0.000 0.000 0.000 192.5.41.41 .INIT. 16 u - 1024
0 0.000 0.000 0.000*10.1.6.250 192.5.41.41 2 u 775 1024 377
33.174 572.967 301.884 10.1.6.251 LOCAL(0) 11 u 597 1024 377 32.821
-59.250 700.218 127.127.1.0 .LOCL. 10 l 5h 64 0 0.000 0.000
0.000[centos@freeipa03 ~]$
LOCAL OFFICE:
[user@freeipa01 ~]$ sudo ntpq -pn remote refid st t when poll reach
delay offset
jitter============================================================================== 10.1.6.250
.INIT. 16 u - 1024 0 0.000 0.000 0.000*192.5.41.41 .PTP.
1 u 105 256 377 39.809 981.095 12.736 10.10.0.31 10.1.6.250 3 u
75 256 377 32.452 -480.57 113.553+192.5.41.40 .PTP. 1 u 130 256
377 42.934 984.052 18.382 10.10.0.32 10.1.6.250 3 u 57 256 377
32.957 -801.93 17.604x10.1.6.251 LOCAL(0) 11 u 84 256 377 0.136
-560.34 1178.40 127.127.1.0 .LOCL. 10 l 157m 64 0 0.000 0.000
0.000[user@freeipa01 ~]$
This is a client server:sudo ntpq -p remote refid st t when poll reach
delay offset
jitter============================================================================== freeipa04.east.
10.1.6.250 3 u 53 64 37 0.413 1316.74 69.142 freeipa03.east. 10.1.6.250
3 u 50 64 37 0.330 1523.74 32.815 freeipa01.stl1. 192.5.41.41 2 u
52 64 37 33.011 2118.44 76.063 freeipa03.stl1. 10.1.6.250 3 u 51 64
37 33.218 2922.96 19.715*LOCAL(0) .LOCL. 5 l 57 64 37
0.000 0.000 0.000
On Tuesday, April 3, 2018 1:27 PM, Andrew Meyer via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Thank you sir. I'll mix up the order of public ntp servers and see what happens.
On Tuesday, April 3, 2018 1:24 PM, Rob Crittenden via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Andrew Meyer wrote:
This is a mix of VMware VMs an AWS instances. All CentOS 7.
It was VMware that had the poor time keeping but this was 7 or 8 years
ago in the Fedora 11/12 time period. I'd find it hard to believe the
same time problems exist today but some googling might turn up something
for you.
rob
On Tuesday, April 3, 2018 1:04 PM, Rob Crittenden <rcritten(a)redhat.com>
wrote:
Andrew Meyer via FreeIPA-users wrote:
> I need some clarification on this. I have my FreeIPA server in
> talking. NTP is working. However Some servers are getting ntp drift.
> If I go into /etc/ntp.conf I see that at the bottom FreeIPA adds server
> at the bottom of the file.
>
> ### Added by IPA Installer ###
> server 127.127.1.0 iburst
> fudge 127.127.1.0 stratum 10
> server 1.2.3.4 # added by /sbin/dhclient-script
> server 5.6.7.8 # added by /sbin/dhclient-script
> server 9.0.1.2 # added by /sbin/dhclient-script
> server 3.4.5.6 # added by /sbin/dhclient-script
> [centos@freeipa03 <mailto:centos@freeipa03> ~]$
>
> But under the public servers at the top should I leave the the centos
> public ntp servers? Should I add the FreeIPA servers?
The theory for making IPA an NTP server was that even if time was off on
the IPA master it would be sharing its same incorrect time with all its
clients so they would all be in the same time universe and things would
continue to work.
It wouldn't hurt if you re-ordered things (I think). Just keep an eye on
it for a while.
Is this real hardware or VMs? In the past (like many moons ago) one
particular VM tech was particularly bad at time keeping so extra work
was needed on the VM host to ensure its RTC was passed into the VMs.
I wonder if connectivity to the centos pool is a problem, or if a VM, it
has bad timing.
rob
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org