Bug 904162
| Summary: | "Unable to sync time with IPA NTP server" while installing ipa-client on IPv6-only network | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Steeve Goveas <sgoveas> | ||||||||||
| Component: | ipa | Assignee: | Rob Crittenden <rcritten> | ||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Namita Soman <nsoman> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 6.4 | CC: | mkosek | ||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2013-01-29 16:21:09 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Steeve Goveas
2013-01-25 16:07:20 UTC
Created attachment 687526 [details]
ipaclient-install.log
Created attachment 687527 [details]
tcpdump from IPA server
Created attachment 687529 [details]
No iptables rules
Created attachment 687532 [details]
grep ntp from messages log
I investigated the issue, at first we need to point out, that this happens only on IPv6 only network (it can be found out in logs you provided and I also know it because I helped you investigate it). I managed to reproduce the issue too, in my case the issue was in a too high stratum of the ntpd server on IPA master machine. This was caused by an inability of the ntpd on IPA server to contact other time servers to sync with as they were available only via IPv4. I also found out that ntpd does not work very well when 127.0.0.1/8 is not present on `lo' interface. `ntpstat' does not work then. Client investigation output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # /usr/sbin/ntpdate -U ntp -b -v -d ipa.rhel64.ad.test 28 Jan 04:18:12 ntpdate[4312]: ntpdate 4.2.4p8 Thu Jan 10 15:17:41 UTC 2013 (1) Looking for host ipa.rhel64.ad.test and service ntp host found : ipa.rhel64.ad.test transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) >>>>>>>>>>>>>>>>>>> 2620:52:0:104c:21a:4aff:fe10:4edc: Server dropped: strata too high server 2620:52:0:104c:21a:4aff:fe10:4edc, port 123 stratum 16, precision -22, leap 11, trust 000 ^^ <<<<<<<<<<<<<<<<<<< refid [2620:52:0:104c:21a:4aff:fe10:4edc], delay 0.02579, dispersion 0.00002 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 1:28:16.000 originate timestamp: d4b0c0d4.ce683131 Mon, Jan 28 2013 4:18:12.806 transmit timestamp: d4b0c0d4.c5fb928c Mon, Jan 28 2013 4:18:12.773 filter delay: 0.02615 0.02580 0.02580 0.02579 0.00000 0.00000 0.00000 0.00000 filter offset: 0.032957 0.032797 0.032788 0.032799 0.000000 0.000000 0.000000 0.000000 delay 0.02579, dispersion 0.00002 offset 0.032799 28 Jan 04:18:12 ntpdate[4312]: no server suitable for synchronization found You can try this command yourself to find the real synchronization failure. (-d puts the synchronization in debug mode). Server investigation output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:1a:4a:10:4e:dc brd ff:ff:ff:ff:ff:ff inet6 2620:52:0:104c:21a:4aff:fe10:4edc/64 scope global dynamic valid_lft 2591982sec preferred_lft 604782sec inet6 fec0:0:a10:4c00:21a:4aff:fe10:4edc/64 scope site dynamic valid_lft 2591982sec preferred_lft 604782sec inet6 fed0:babe:baab:0:21a:4aff:fe10:4edc/64 scope site dynamic valid_lft 86382sec preferred_lft 14382sec inet6 fe80::21a:4aff:fe10:4edc/64 scope link valid_lft forever preferred_lft forever # ntpstat On connect: Network is unreachable unable to connect to socket # ntpq ntpq> peers remote refid st t when poll reach delay offset jitter ============================================================================== LOCAL(0) .LOCL. 10 - 9 64 77 0.000 0.000 0.000 10.5.27.10 .INIT. 16 - - 64 0 0.000 0.000 0.000 10.11.160.238 .INIT. 16 - - 64 0 0.000 0.000 0.000 10.16.255.1 .INIT. 16 - - 64 0 0.000 0.000 0.000 10.5.26.10 .INIT. 16 - - 64 0 0.000 0.000 0.000 ntpq> ^D However, in my case when I waited several minutes, the server gave up synchronizing with unavailable IPv4 peers and client ntp synchronization then worked: /usr/sbin/ntpdate -U ntp -b -v -d ipa.rhel64.ad.test 28 Jan 04:27:09 ntpdate[4341]: ntpdate 4.2.4p8 Thu Jan 10 15:17:41 UTC 2013 (1) Looking for host ipa.rhel64.ad.test and service ntp host found : ipa.rhel64.ad.test transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) receive(2620:52:0:104c:21a:4aff:fe10:4edc) transmit(2620:52:0:104c:21a:4aff:fe10:4edc) server 2620:52:0:104c:21a:4aff:fe10:4edc, port 123 <<<<<<<<<<<<<< stratum 11, precision -22, leap 00, trust 000 refid [2620:52:0:104c:21a:4aff:fe10:4edc], delay 0.02580, dispersion 0.00005 transmitted 4, in filter 4 >>>>>>>>>>>>>> reference time: d4b0c2dc.05cd1168 Mon, Jan 28 2013 4:26:52.022 originate timestamp: d4b0c2ed.76d326ac Mon, Jan 28 2013 4:27:09.464 transmit timestamp: d4b0c2ed.73c8145e Mon, Jan 28 2013 4:27:09.452 filter delay: 0.02686 0.02582 0.02582 0.02580 0.00000 0.00000 0.00000 0.00000 filter offset: 0.012215 0.011760 0.011756 0.011759 0.000000 0.000000 0.000000 0.000000 delay 0.02580, dispersion 0.00005 offset 0.011759 28 Jan 04:27:09 ntpdate[4341]: step time server 2620:52:0:104c:21a:4aff:fe10:4edc offset 0.011759 sec Anyway, if this is the case also for your environment, I do not think this is an IPA issue, but rather a wrong network configuration. Steeve, do you agree with closing this bug report or do you have any additional comments or findings? Yes, agreed. It was the same case for my environment. Thanks Martin. Closing the bug. |