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