Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 249226 - ntpd cannot find interfaces for specified servers
ntpd cannot find interfaces for specified servers
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-22 23:15 EDT by Bojan Smojver
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version: 4.2.4p2-3.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-29 13:30:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of ntpd -n -D 4 (23.10 KB, text/plain)
2007-07-24 18:40 EDT, Bojan Smojver
no flags Details

  None (edit)
Description Bojan Smojver 2007-07-22 23:15:03 EDT
Description of problem:
As of ntpd-4.2.4p2-1.fc7, ntpd reports "Cannot find existing interface for
address <address_of_the_ntp_server>" and cannot sync the time off those servers.
The configuration is:

server 0.fedora.pool.ntp.org
server 1.fedora.pool.ntp.org
server 2.fedora.pool.ntp.org

Adding "dynamic" to the above cleans up the error from the logfile, but "ntpd
-p" still reports that we're synced to "LOCAL(0)" instead of any of the servers.
ntpdate command successfully syncs from the desired servers - this is not a
firewall/SELinux issue for sure. Changing servers (e.g. clock[123].redhat.com
doesn't make any difference either.

Downgrading to ntp-4.2.4p0-2.fc7 fixes the problem.

Version-Release number of selected component (if applicable):
ntp-4.2.4p2-1.fc7

How reproducible:
Always.

Steps to Reproduce:
1. Configure NTP to sync off servers on the Internet.
2. Start ntpd.
  
Actual results:
No sync.

Expected results:
Should sync, like the previous version.

Additional info:
Comment 1 Miroslav Lichvar 2007-07-23 03:42:02 EDT
Do you have any -I or -L options in /etc/sysconfig/ntpd?

If not, please start ntpd -n -D 4 and attach the output here.
Comment 2 Bojan Smojver 2007-07-23 17:37:13 EDT
No, /etc/sysconfig/ntpd is stock Fedora file.

Bummer - I've been running that (the ntpd in debug mode) all morning yesterday
to see what's going on, but haven't saved any output. I guess I'll have to do it
all over again :-(
Comment 3 Miroslav Lichvar 2007-07-24 06:17:48 EDT
I just want to see the output when ntpd is binding to interfaces, running ntpd
for 1 minute is enough. 
Comment 4 Bojan Smojver 2007-07-24 18:40:20 EDT
Created attachment 159893 [details]
Output of ntpd -n -D 4
Comment 5 Miroslav Lichvar 2007-07-25 17:20:50 EDT
Thanks. Looks like the lo:0 interface has the same address as ppp0.

Can you please test the 4.2.4p0-3 and see if it has the same problem?
http://koji.fedoraproject.org/packages/ntp/4.2.4p0/3.fc8/i386/ntp-4.2.4p0-3.fc8.i386.rpm

Please post also output from /sbin/ip addr.
Comment 6 Bojan Smojver 2007-07-25 17:36:59 EDT
> Looks like the lo:0 interface has the same address as ppp0.

That's on purpose. However, I've got:

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2

in /etc/sysctl.conf, so the address should never get advertised anywhere. It's
just a "sink" for when ppp0 goes down, so that things still work on the box as
expected.

The output of "ip addr" is:
-------------------------------------------------
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 203.171.74.242/32 brd 203.171.74.242 scope global lo:0
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master bond0 qlen 1000
    link/ether 00:03:47:ce:b7:e3 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::203:47ff:fece:b7e3/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master bond0 qlen 1000
    link/ether 00:03:47:ce:b7:e3 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::203:47ff:fece:b7e3/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:a0:c9:03:ae:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global eth2
    inet6 fe80::2a0:c9ff:fe03:ae70/64 scope link 
       valid_lft forever preferred_lft forever
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue 
    link/ether 00:03:47:ce:b7:e3 brd ff:ff:ff:ff:ff:ff
    inet 172.27.0.1/16 brd 172.27.255.255 scope global bond0
    inet6 fe80::203:47ff:fece:b7e3/64 scope link tentative 
       valid_lft forever preferred_lft forever
8: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast qlen 3
    link/ppp 
    inet 203.171.74.242 peer 202.63.35.1/32 scope global ppp0
-------------------------------------------------

The RPM you pointed to works OK:
-------------------------------------------------
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*clock1.redhat.c .CDMA.           1 u   55   64   37  306.583    0.605   0.185
 clock2.redhat.c .CDMA.           1 u   50   64   37  309.944   -0.608   0.237
+clock3.redhat.c .CDMA.           1 u   53   64   37  257.912   25.403   1.943
 LOCAL(0)        .LOCL.          10 l   51   64   37    0.000    0.000   0.001
-------------------------------------------------
Comment 7 Miroslav Lichvar 2007-07-30 11:32:35 EDT
Ok, I've reproduced the problem. The reason why ntp-4.2.4p0 works is that it
doesn't check if the interface found for the peer is loopback. ntp-4.2.4p2 does
that and ignores lo:0 interface.
Comment 8 Bojan Smojver 2007-07-30 21:44:34 EDT
Strange... Even if lo:0 is ignored, things should work as there is another
interface (ppp0) that can (and should) be used for this.

More generally, any machine that is part of a cluster that uses direct routing
would have such loopback interfaces set up, making ntpd fail on it. I currently
don't have access to any such setups, but if can put you hands on one at Red
Hat, maybe you can give it a try there as well.
Comment 9 Miroslav Lichvar 2007-07-31 09:22:55 EDT
Hm, virtual servers usually have virtual IP address different from the real
address on physical interface. At least, I couldn't find an example where the
addresses are identical ;).

The problem is that ntpd tracks interfaces by their addresses, so ppp0 is
skipped as duplicate of lo:0.
Comment 10 Bojan Smojver 2007-07-31 17:57:51 EDT
I thought from your original explanation that the problem is having the loopback
itself. I see now that ntpd makes some assumptions about the configuration of
interfaces that may not be quite right.

For instance, machines doing proxy arp may have two NICs with identical IPs
configured on the same box, so that may be a perfectly valid configuration from
the kernel's point of view. At least no other software complained so far...
Comment 11 Miroslav Lichvar 2007-08-07 07:22:49 EDT
Upstream bug report filed at:
https://support.ntp.org/bugs/show_bug.cgi?id=882

Comment 12 Bojan Smojver 2007-08-07 21:16:32 EDT
Thanks.
Comment 13 Fedora Update System 2007-08-13 13:04:08 EDT
ntp-4.2.4p2-2.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 14 Bojan Smojver 2007-08-13 17:22:19 EDT
Looking good here. Thanks!

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 clock1.redhat.c .INIT.          16 u    -   64    0    0.000    0.000   0.000
+clock2.redhat.c .CDMA.           1 u   37   64   77  316.227  -30.580   0.585
*clock3.redhat.c .CDMA.           1 u   36   64   77  247.306   -0.682   1.216
 LOCAL(0)        .LOCL.          10 l   39   64   77    0.000    0.000   0.001
Comment 15 Fedora Update System 2007-08-24 01:31:44 EDT
ntp-4.2.4p2-3.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2007-08-29 13:30:12 EDT
ntp-4.2.4p2-3.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.