[opensuse] puzzle of the week - any ntp experts out there?
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference: An ntp client (A) that uses the ipv6 multicast: # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378 An ntp client (B) that is configured as ipv4 broadcastclient: # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283 The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2? Here it is quite clear, the ipv4 connection is preferred over the ipv6 multicast: # ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.254 .DCFa. 1 u 245 256 377 0.378 6.466 1.371 xfe80::202:a5ff: 192.168.2.254 2 m 4 16 377 0.288 117.385 0.458 I know this would be better asked on the ntp list, but still :-) -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
13.03.2016 21:35, Per Jessen пишет:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
What "it" you mean? A sees stratum 2 server fe80::202:a5ff: which itself has as reference clock stratum 1 server. What exactly is wrong here? Your question sounds like "it" is the same server, but you gave no evidence that fe80::202:a5ff: is the same as 192.168.2.137.
Here it is quite clear, the ipv4 connection is preferred over the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.254 .DCFa. 1 u 245 256 377 0.378 6.466 1.371 xfe80::202:a5ff: 192.168.2.254 2 m 4 16 377 0.288 117.385 0.458
I know this would be better asked on the ntp list, but still :-)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
13.03.2016 21:35, Per Jessen пишет:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
What "it" you mean? A sees stratum 2 server fe80::202:a5ff: which itself has as reference clock stratum 1 server. What exactly is wrong here? Your question sounds like "it" is the same server, but you gave no evidence that fe80::202:a5ff: is the same as 192.168.2.137.
Sorry, yes, _it_ is the same server. -- Per Jessen, Zürich (3.9°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Mar 14, 2016 at 10:12 AM, Per Jessen
Andrei Borzenkov wrote:
13.03.2016 21:35, Per Jessen пишет:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
What "it" you mean? A sees stratum 2 server fe80::202:a5ff: which itself has as reference clock stratum 1 server. What exactly is wrong here? Your question sounds like "it" is the same server, but you gave no evidence that fe80::202:a5ff: is the same as 192.168.2.137.
Sorry, yes, _it_ is the same server.
How do you know it? ntpq -np displays truncated IPv6 address, so you do not even see what server is used. See http://bugs.ntp.org/show_bug.cgi?id=1128 how to show verify full peer address. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 10:12 AM, Per Jessen
wrote: Andrei Borzenkov wrote:
What "it" you mean? A sees stratum 2 server fe80::202:a5ff: which itself has as reference clock stratum 1 server. What exactly is wrong here? Your question sounds like "it" is the same server, but you gave no evidence that fe80::202:a5ff: is the same as 192.168.2.137.
Sorry, yes, _it_ is the same server.
How do you know it? ntpq -np displays truncated IPv6 address, so you do not even see what server is used.
It's our own server, in the datacentre downstairs.
See http://bugs.ntp.org/show_bug.cgi?id=1128 how to show verify full peer address.
Well, the full IPv6 address is fe80::202:a5ff:fe2c:f2b4. -- Per Jessen, Zürich (3.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Mar 14, 2016 at 10:59 AM, Per Jessen
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 10:12 AM, Per Jessen
wrote: Andrei Borzenkov wrote:
What "it" you mean? A sees stratum 2 server fe80::202:a5ff: which itself has as reference clock stratum 1 server. What exactly is wrong here? Your question sounds like "it" is the same server, but you gave no evidence that fe80::202:a5ff: is the same as 192.168.2.137.
Sorry, yes, _it_ is the same server.
How do you know it? ntpq -np displays truncated IPv6 address, so you do not even see what server is used.
It's our own server, in the datacentre downstairs.
See http://bugs.ntp.org/show_bug.cgi?id=1128 how to show verify full peer address.
Well, the full IPv6 address is fe80::202:a5ff:fe2c:f2b4.
OK, let's start from the beginning. You have single NTP stratum 1 server with 2 IPv4 and some IPv6 addresses, correct? You provided three "ntpq -np" outputs; the first two are from clients A dnd B; where does the third one comes from? Could you show full "ip a l" from each server with clear indication what server it is /etc/ntp.conf from the same (grep -v '^#' /etc/ntp.conf to remove comments) ntpq -wnp (assuming ntpq support -w in our case) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
OK, let's start from the beginning. You have single NTP stratum 1 server with 2 IPv4 and some IPv6 addresses, correct?
Pretty much - all of the three servers involved have two networks, internal and external, but only the internal is interesting here.
You provided three "ntpq -np" outputs; the first two are from clients A dnd B; where does the third one comes from?
The third one was also from (B), just a while later. On (B), server 192.168.2.254 is added by DHCP.
Could you show full
"ip a l" from each server with clear indication what server it is /etc/ntp.conf from the same (grep -v '^#' /etc/ntp.conf to remove comments) ntpq -wnp (assuming ntpq support -w in our case)
------------- (A) ---------------
Server (A) aka "hamburg":
hamburg:~ # ip a l ( (have omitted the loopback))
2: eth0:
On 2016-03-13 19:35, Per Jessen wrote:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
Wild wild guess. The the time server is acting dual head (if such a thing is possible), and the head acting as IPv6 server takes the reference from the IPv4 head.
I know this would be better asked on the ntp list, but still :-)
Quite. When you do, I'd be curious to know the answer :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Mon, Mar 14, 2016 at 11:14 AM, Carlos E. R.
On 2016-03-13 19:35, Per Jessen wrote:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
Wild wild guess. The the time server is acting dual head (if such a thing is possible), and the head acting as IPv6 server takes the reference from the IPv4 head.
Yes, it looks like this, but still the question is how to verify it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 11:14 AM, Carlos E. R.
wrote: On 2016-03-13 19:35, Per Jessen wrote:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
Wild wild guess. The the time server is acting dual head (if such a thing is possible), and the head acting as IPv6 server takes the reference from the IPv4 head.
Yes, it looks like this, but still the question is how to verify it.
And then explain why. The time server serves time with this config; broadcast 192.168.7.255 minpoll 4 multicast ff05::101 minpoll 4 key 1 -- Per Jessen, Zürich (4.0°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Mar 14, 2016 at 12:02 PM, Per Jessen
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 11:14 AM, Carlos E. R.
wrote: On 2016-03-13 19:35, Per Jessen wrote:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
Wild wild guess. The the time server is acting dual head (if such a thing is possible), and the head acting as IPv6 server takes the reference from the IPv4 head.
Yes, it looks like this, but still the question is how to verify it.
And then explain why.
The time server serves time with this config;
broadcast 192.168.7.255 minpoll 4 multicast ff05::101 minpoll 4 key 1
Well, without IP config from server it is hard to guess. You can send it privately if you think it is sensitive, or obfuscate public IP addresses (I want to see link local addresses in the first place). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 12:02 PM, Per Jessen
wrote: Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 11:14 AM, Carlos E. R.
wrote: On 2016-03-13 19:35, Per Jessen wrote:
This one's amusing (well, it depends) - I've been playing with ntp multicast on ipv6 for a while. It works very well (on ff05::101), but today I noticed a tiny difference:
An ntp client (A) that uses the ipv6 multicast:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*fe80::202:a5ff: 192.168.2.254 2 m 12 16 376 -0.388 -23.481 2.378
An ntp client (B) that is configured as ipv4 broadcastclient:
# ntpq -pn remote refid st t when poll reach delay offset jitter
==============================================================================
*192.168.2.137 .DCFa. 1 u 13 16 376 0.266 0.026 0.283
The time server (192.168.2.137,192.168.2.254) has a DCF77 receiver, and is stratum 1. Notice the _refid_. The question is - why does (B) see the time server as stratum 1, when (A) sees it as stratum 2?
Wild wild guess. The the time server is acting dual head (if such a thing is possible), and the head acting as IPv6 server takes the reference from the IPv4 head.
Yes, it looks like this, but still the question is how to verify it.
And then explain why.
The time server serves time with this config;
broadcast 192.168.7.255 minpoll 4 multicast ff05::101 minpoll 4 key 1
Well, without IP config from server it is hard to guess. You can send it privately if you think it is sensitive, or obfuscate public IP addresses (I want to see link local addresses in the first place).
Sorry, it's not sensitive -
dresden:/srv/tftpboot # ip a l (have omitted loopback and a tunnel)
2: eth0:
On Mon, Mar 14, 2016 at 12:13 PM, Per Jessen
Haha, okay, I see part of the problem. There is in fact _two_ time servers multicasting on IPv6 on this network. The primary is above, the second one is fe80::202:a5ff:fe2c:f2b4.
:) So can this be considered solved? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 12:13 PM, Per Jessen
wrote: Haha, okay, I see part of the problem. There is in fact _two_ time servers multicasting on IPv6 on this network. The primary is above, the second one is fe80::202:a5ff:fe2c:f2b4.
:)
So can this be considered solved?
Yes, thanks, you get three points for being helpful, as always. Why the primary time server fails to do any ipv6 multicasting is a separate issue, I suspect it's simply too old. /Per -- Per Jessen, Zürich (4.1°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 12:13 PM, Per Jessen
wrote: Haha, okay, I see part of the problem. There is in fact _two_ time servers multicasting on IPv6 on this network. The primary is above, the second one is fe80::202:a5ff:fe2c:f2b4.
:)
So can this be considered solved?
Yes, thanks, you get three points for being helpful, as always. Why the primary time server fails to do any ipv6 multicasting is a separate issue, I suspect it's simply too old.
Er ... no, operator error. In /etc/ntp.conf I had: "multicast ff05::101 minpoll 4 key 1", but correct would be "broadcast ff05::101 minpoll 4 key 1". The IPv6 multicast works fine now. -- Per Jessen, Zürich (4.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (3)
-
Andrei Borzenkov
-
Carlos E. R.
-
Per Jessen