On 2014-04-02, Sander Smeenk <[email protected]> wrote: > Quoting [email protected]: > >> > if i check 'ntpq -c lpeers' on one of the three stratum-2 servers i >> > see an IP-address listed as 'refid' for the 'peer'-entries in my >> >> No, its in ntp{1,2,3}.bit.nl's .conf, or via DHCP or >> ntp{1,2,3}.bit.nl ntp servers got it via a pool command. Why are you >> using ntp{1,2,3}.bit.nl / dns{1,2,3}.dns.dmz.bit.nl servers? Why do >> you care what ntp{1,2,3}.bit.nl / dns{1,2,3}.dns.dmz.bit.nl respond >> with for their refclock? > > I am root@ntp{1,2,3}. I am the sysadmin of ntp{1,2,3} and > tt52.ripe.net. I have 15 years of experience with Linux, networks, > routing, the works. I care what these servers report as refid > because i administer them and my users notified me about this weird > IP-address.
Its a 32 bit value used for loop detection. As stated by Dr. Mills (at http://lists.ntp.org/pipermail/ntpwg/2005-June/000087.html): | Stratum Reference ID | 0 (undefined) a 4-octet, zero padded string (kiss code) | 1 (primary) reference clock designator (e.g., WWVB) | 2-255 (secondary) IPv4: IPv4 address | IPv6: first 32 bits of the MD5 hash of the IPv6 address According to RFC5905 (http://www.ietf.org/rfc/rfc5905.txt) page 21 | Reference ID (refid): 32-bit code identifying the particular server | or reference clock. The interpretation depends on the value in the | stratum field. For packet stratum 0 (unspecified or invalid), this | is a four-character ASCII [RFC1345] string, called the "kiss code", | used for debugging and monitoring purposes. For stratum 1 (reference | clock), this is a four-octet, left-justified, zero-padded ASCII string | assigned to the reference clock. The authoritative list of Reference | Identifiers is maintained by IANA; however, any string beginning with | the ASCII character "X" is reserved for unregistered experimentation | and development. The identifiers in Figure 12 have been used as ASCII | identifiers: [snip --> Figure 12: Reference Identifiers] | Above stratum 1 (secondary servers and clients): this is the reference | identifier of the server and can be used to detect timing loops. If | using the IPv4 address family, the identifier is the four-octet IPv4 | address. If using the IPv6 address family, it is the first four octets | of the MD5 hash of the IPv6 address. Note that, when using the IPv6 | address family on an NTPv4 server with a NTPv3 client, the Reference | Identifier field appears to be a random value and a timing loop might | not be detected. Unfortunately a bad precedent was set with IPv4 by displaying the refid as an IP address rather than as a GUUID. And users have become accustomed to this misrepresentation. The ntpq display formatting routine treats all 32-bit refids identically and renders them as IPv4 addresses (see http://bugs.ntp.org/278#c7 for a possible rationale). References: http://bugs.ntp.org/278 (reported 2004-02-03) http://bugs.ntp.org/505 http://lists.ntp.org/pipermail/questions/2005-December/008271.html http://lists.ntp.org/pipermail/ntpwg/2005-June/000086.html http://www.ietf.org/rfc/rfc5905.txt http://support.ntp.org/bin/view/Dev/UpdatingTheRefidFormat http://doc.ntp.org/4.2.6p5/debug.html -- Steve Kostecke <[email protected]> NTP Public Services Project - http://support.ntp.org/ _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
