[ntp:questions] Re: refid on client differs from refid on local server

David L. Mills mills at udel.edu
Fri Dec 16 20:13:28 UTC 2005


Danny,

I'm not aware of any mission calculated to "change my mind," much less 
whether to attempt DNS deconstruction of the refid field, on which I 
have no opinion. If the reference stratum is 0 or 16 or a reference 
clock, the refid is reported as a string, otherwise the opaque value. 
What ntpq or ntpdc does with that is opaque to me, but they would have 
to figure out which to print based on the same criteria.

The common problem occurs when running a reference clock driver at 
elevated stratum, in which case the refid used to look like a mangled IP 
address, but now reveals the clock type instead. This should have 
nothing to do with DNS. Is this what you meant by "change my mind?"

Dave

Danny Mayer wrote:
> Nigel Henry wrote:
> 
>>With a bit of help from Danny in commenting out restrict lines, I now have NTP 
>>working well with my 2 Linux servers and multiple Linux clients on the other 
>>machine. One small query is. The refid's on the client distro's, when running 
>>ntpq> pe show the original IP address, as on the website for the stratum 2 
>>servers, but the refid IP addresses on my server ,are different. Why is this 
>>so? Also the other distro I use as a server (FC1) just shows alternative 
>>hostnames under refid for the same servers. Admittadly FC1 is using a 
>>slightly earlier version of NTP. A few details below, and the relevant ntpq> 
>>pe outputs below that.
>>
>>FC2-server is using ntp-4.2.0-7
>>FC1-server is using ntp-4.1.2-5
>>FC2-client (as an example, as I have many clients) is using ntp-4.2.0-7
>>
>>This is the ntpq> pe for the FC2 server
>>
>>ntpq> pe
>>     remote           refid      st t when poll reach   delay   offset  jitter
>>==============================================================================
>>+lptfpc46.obspm. 195.220.94.163   2 u   89  128  377  136.809    3.547 175.646
>>*ntp.kamino.fr   193.52.184.106   2 u  101  128  377  287.905    1.165  59.055
>>+ntp2.belbone.be 195.13.23.250    2 u   99  128  377  142.793  -62.327  53.907
>>ntpq>
>>
>>This is the ntpq> pe for the FC2 client. One of many clients on this machine
>>
>>ntpq> pe
>>     remote           refid      st t when poll reach   delay   offset  jitter
>>==============================================================================
>>*192.168.0.230   216.32.94.18     3 u   79  128  377    0.422   32.474   8.907
>> 192.168.0.228   .INIT.          16 u    - 1024    0    0.000    0.000 4000.00
>>ntpq>
>>
>>This is the ntpq> pe for the FC1 server, on the same machine as the FC2 
>>server, but showing alternative hostnames, rather than IP addresses under 
>>refid
>>
>>ntpq> pe
>>     remote           refid      st t when poll reach   delay   offset  jitter
>>==============================================================================
>>*lptfpc46.obspm. horlogegps.rese  2 u  106  128  377  128.493  -51.345   0.757
>>+ntp.kamino.fr   saturne.obs-bes  2 u  104  256  377  279.962  -70.196   7.481
>>+ntp2.belbone.be ntp0.belbone.be  2 u   44  256  377  135.129  -61.765   0.378
>>ntpq> pe
>>
>>None of this is any big deal as NTP appears to be working very well and all my 
>>clocks are synched, but I would like to have an explanation to my query. 
>>Nigel.
> 
> 
> Sigh. Please repeat after me: A refid is NOT an IP address, it's a
> 32-bit number that is used for loop prevention.
> 
> It was a mistake to allow it to be translated into a host name or
> display it as anything but a hex number. Things get much worse with IPv6
> where the refid looks like an IPv4 address but is in fact a mangled IPv6
> address MD5 hash. I've been trying to pursuade Dave to agree to change
> the display format at least in the beginning.
> 
> Danny
> _______________________________________________
> questions mailing list
> questions at lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 




More information about the questions mailing list