[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 <per@computer.org> wrote:
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 <per@computer.org> 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 <per@computer.org> wrote:
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 10:12 AM, Per Jessen <per@computer.org> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:16:3e:a3:22:47 brd ff:ff:ff:ff:ff:ff inet 192.168.2.144/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fea3:2247/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 00:16:3e:a3:22:48 brd ff:ff:ff:ff:ff:ff inet 185.85.248.15/27 brd 185.85.248.31 scope global eth1 valid_lft forever preferred_lft forever inet 185.85.248.16/27 scope global secondary eth1 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fea3:2248/64 scope link valid_lft forever preferred_lft forever hamburg:~ # egrep -v '^#|^$' /etc/ntp.conf driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp keys /etc/ntp.keys trustedkey 1 requestkey 1 multicastclient ff05::101 restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify noquery restrict 127.0.0.1 restrict ::1 hamburg:~ # ntpq -npc "rv &2" (ntpq doesn't support -w) remote refid st t when poll reach delay offset jitter ============================================================================== *fe80::202:a5ff: 192.168.2.137 2 m 15 16 376 -0.037 2.162 0.383 associd=11099 status=763a authenb, auth, reach, sel_sys.peer, 3 events, sys_peer, srcadr=fe80::202:a5ff:fe2c:f2b4, srcport=123, dstadr=ff05::101, dstport=123, leap=00, stratum=2, precision=-21, rootdelay=2.426, rootdisp=112.503, refid=192.168.2.137, reftime=da90f456.c39c82de Mon, Mar 14 2016 9:27:02.764, rec=da90f9cc.c26195b8 Mon, Mar 14 2016 9:50:20.759, reach=376, unreach=0, hmode=6, pmode=5, hpoll=4, ppoll=4, headway=0, flash=00 ok, keyid=1, offset=2.162, delay=-0.037, dispersion=0.233, jitter=0.383, xleave=0.077, ------------- (B) --------------- Server (B) aka "guest54": guest54:~ # ip a l (have omitted the loopback) 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 7a:11:a2:12:35:22 brd ff:ff:ff:ff:ff:ff inet 192.168.7.54/21 brd 192.168.7.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::7811:a2ff:fe12:3522/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether 7a:11:a2:12:35:23 brd ff:ff:ff:ff:ff:ff inet 185.85.248.29/27 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::7811:a2ff:fe12:3523/64 scope link valid_lft forever preferred_lft forever guest54:~ # egrep -v '^#|^$' /etc/ntp.conf driftfile /var/lib/ntp/drift/ntp.drift logfile /var/log/ntp keys /etc/ntp.keys trustedkey 1 requestkey 1 restrict -4 default kod notrap nomodify nopeer noquery restrict -6 default kod notrap nomodify noquery restrict 127.0.0.1 restrict ::1 multicastclient ff05::101 guest54:~ # ntpq -npc "rv &2" remote refid st t when poll reach delay offset jitter ============================================================================== *192.168.2.254 .DCFa. 1 u 549 1024 377 0.338 0.114 2.040 xfe80::202:a5ff: 192.168.2.137 2 m 13 16 376 0.288 88.437 1.602 associd=35761 status=711a authenb, auth, reach, sel_falsetick, 1 event, sys_peer, srcadr=fe80::202:a5ff:fe2c:f2b4, srcport=123, dstadr=ff05::101, dstport=123, leap=00, stratum=2, precision=-21, rootdelay=2.426, rootdisp=114.655, refid=192.168.2.137, reftime=da90f456.c39c82de Mon, Mar 14 2016 9:27:02.764, rec=da90fa5c.ac545f1b Mon, Mar 14 2016 9:52:44.673, reach=376, unreach=0, hmode=6, pmode=5, hpoll=4, ppoll=4, headway=0, flash=00 ok, keyid=1, offset=88.437, delay=0.288, dispersion=0.233, jitter=1.602, xleave=0.046, -- 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
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. <robin.listas@telefonica.net> 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. -- 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. <robin.listas@telefonica.net> 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 <per@computer.org> wrote:
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 11:14 AM, Carlos E. R. <robin.listas@telefonica.net> 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 <per@computer.org> wrote:
Andrei Borzenkov wrote:
On Mon, Mar 14, 2016 at 11:14 AM, Carlos E. R. <robin.listas@telefonica.net> 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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:08:02:58:7f:ac brd ff:ff:ff:ff:ff:ff inet 192.168.2.137/21 brd 192.168.7.255 scope global eth0 inet 192.168.2.254/21 brd 192.168.7.255 scope global secondary eth0 inet6 2a03:7520:4c68:1::1000/64 scope global valid_lft forever preferred_lft forever inet6 fe80::208:2ff:fe58:7fac/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:08:02:58:7f:ab brd ff:ff:ff:ff:ff:ff inet 185.85.248.2/27 brd 185.85.248.31 scope global eth1 inet6 2a03:7520:4c68::1000/64 scope global valid_lft forever preferred_lft forever inet6 2a03:7520:4c68::2137/64 scope global valid_lft forever preferred_lft forever inet6 fe80::208:2ff:fe58:7fab/64 scope link valid_lft forever preferred_lft forever 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. Funny thing is, although the primary server has been configured to do multicasts, it doesn't actually do any. It's a bit backlevel, maybe ntpd doesn't quite support it. -- Per Jessen, Zürich (4.0°C) http://www.dns24.ch/ - your free DNS host, 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:13 PM, Per Jessen <per@computer.org> 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? -- 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 <per@computer.org> 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 <per@computer.org> 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