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
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
