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@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@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 <rcrit...@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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
