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