[ntp:questions] Three NTP servers, one strange IP-address in 'refid'

Steve Kostecke kostecke at ntp.org
Wed Apr 2 13:12:23 UTC 2014


On 2014-04-02, Sander Smeenk <ssmeenk at freshdot.net> wrote:

> Quoting Null at BlackList.Anitech-Systems.invalid:
>
>> > 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 at 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 <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/



More information about the questions mailing list