NTP, strange address ...

[RiclyLeRoy]

My ntp server ALFA (among public/private network) said:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 193.204.114.232 .CTD.            1 u   47   64    7   20.984  -245.80  68.630
 193.204.114.233 .CTD.            1 u   44   64    7   20.880  -176.13 112.659
 131.188.3.221   .DCFp.           1 u   43   64    7   42.967  -183.84 112.828
 193.79.237.14   .PPS.            1 u   45   64    7   26.773  -245.78  70.748

While my 3 ntp servers (BETA1,2,3) in private network retrieve time from ALFA:

BETA1:

     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
ALFA    83.84.69.80     16 u   31 1024  377     0.96  -3257.9  847.20

BETA2:

     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
 ALFA       83.84.69.80     16 u  149 1024  377     0.90  -3468.4  896.53

BETA3:

     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
ALFA    83.84.69.80     16 u  194 1024  377     0.66  -3311.0  856.48

If I type this command 'ntpdate -d ALFA' from BETA1,2,3 I get: 

transmit(ALFA)
receive(ALFA)
transmit(ALFA)
receive(ALFA)
transmit(ALFA)
receive(ALFA)
transmit(ALFA)
receive(ALFA)
transmit(ALFA)
server ALFA, port 123
stratum 16, precision -18, leap 00, trust 000
refid [83.84.69.80], delay 0.02586, dispersion 0.00000
transmitted 4, in filter 4
reference time:      d5e29623.a29b280f  Tue, Sep 17 2013 10:49:39.635
originate timestamp: d5e2bbfb.5f5d7881  Tue, Sep 17 2013 13:31:07.372
transmit timestamp:  d5e2bbfe.58649000  Tue, Sep 17 2013 13:31:10.345
filter delay:  0.02602  0.02596  0.02586  0.02589
               0.00000  0.00000  0.00000  0.00000
filter offset: -2.97296 -2.97296 -2.97296 -2.97296
               0.000000 0.000000 0.000000 0.000000
delay 0.02586, dispersion 0.00000
offset -2.972962

My clients use all 3 servers (BETA1,2,3) as TIME SERVER reference

What address is 83.84.69.80 in BETA1,2,3 !??!?! I didn't configure it. What do you think ?

Why offset in ALFA is too high ?!?!

 While I restart daemon on BETA1,2,3 I get:

 no server suitable for synchronization found

[Ajin_1]

Check  /etc/ntp.conf file and /etc/hosts file entry.

[RiclyLeRoy]

It't the first thing which I checked, no entries in both files.

[Matti_Kurkela]

Then I guess the BETA1-3 systems are probably using DNS to find the IP address of ALFA.

Could it be that the DNS server in the private network has the wrong IP address for ALFA?

Your ALFA server apparently has NTP connectivity to several stratum-1 time sources, which is excellent... but there is no asterisk (*) anywhere in the first column, so it has not actually synced with any of those yet. In that situation, ALFA should not be providing NTP information to the clients yet.

Please run "ntpq -np" on your BETA1-3 servers to see the "remote" field in the form of an IP address, and see if that IP address is correct.

I'm guessing that the BETA1-3 servers are receiving an incorrect IP address for ALFA from DNS, and end up talking to something other than the real ALFA. That "fake ALFA" indicates stratum 16 (= the "quality" of time information, the worst possible value). That would place the BETA1-3 servers to stratum 17, which is an impossible value in the NTP protocol, so they cannot sync with this time source.

The 83.84.69.80 in the refid field indicates the IP address the fake ALFA is getting its NTP information from. On stratum-1 NTP servers, the refid is replaced by the reference clock driver identifier: for example, the .PPS. indicates a reference clock with a generic pulse-per-second signal.

I once saw similar behavior (passing out useless NTP time information with stratum 16) with a NTP-enabled router or firewall device. Once I informed the network administrator that there was a problem with the NTP information, he fixed it somehow. But I think this suggests the "fake ALFA" might also be a router or a similar network device.

[RiclyLeRoy]

>Then I guess the BETA1-3 systems are probably using DNS to find the IP address of ALFA.

In ntp.conf of BETA1-3 it's specified IP of ALFA server, so it's not necessary to solve name.

ALFA is a virtual machine

[Matti_Kurkela]

OK. So if the IP address is correct, is there a load balancer, a NAT device or other Layer-3 network device between ALFA and the BETA1-3 servers? 

Such a device might be redirecting the connection to some other host.