[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