[ntp:questions] NTP multicast client appears to work in unicast...
Danny Mayer
mayer at ntp.isc.org
Thu Apr 6 21:10:42 UTC 2006
Tim wrote:
> Hi, here is my problem. (I use NTP 4..2.0 version on both machines)
> I have an NTP server wich use the multicast mode... here is the
> ntp.conf for this machine:
>
> server 0.europe.pool.ntp.org iburst
> server 1.europe.pool.ntp.org iburst
> server 2.europe.pool.ntp.org iburst
> broadcast 224.0.1.1 key 1 ttl 1
> driftfile /etc/ntp.drift
> keys /etc/ntp.keys
> trustedkey 1
> trustedkey 2
> trustedkey 3
> enable auth
> controlkey 1
> requestkey 1
>
> So I set a client machine in multicastclient mode. Here is its ntp.conf
> keys /etc/ntp.keys
> trustedkey 1
> multicastclient 224.0.1.1
> #broadcastclient
> driftfile /etc/ntp.drift
> statistics loopstats
> statsdir /var/log/ntp/
> filegen peerstats file peers type day link enable
> filegen loopstats file loops type day link enable
>
> The content of ntp.keys file are the same. It's MD5 keys... so here is
> the problem. I start my server, ntpq -p shows:
> [root at linux2400 tar]# ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> +discovery.jonep 80.239.2.130 3 u 30 32 377 121.375 0.541
> 10.825
> *80-28-46-78.ads 150.214.94.5 2 u 31 32 376 133.226 1.820
> 5.949
> +skylar.fbagroup 193.62.22.98 2 u 29 32 377 68.968 -0.755
> 5.616
> NTP.MCAST.NET .MCST. 16 u - 64 0 0.000 0.000
> 4000.00
> wich is quite normal.
> Now, when I start the client, ntpq -p gives:
> ntpq -p
> No association ID's returned
> So I think It's normal, the 8 packets exchange must be done in order to
> enter in the multicast mode but the problem is the result giver with
> ntpq -p after. It shows:
> ntpq -p
> remote refid st t when poll reach delay offset
> jitter
> ==============================================================================
> *192.168.1.20 80.28.46.78 3 u 39 1024 77 0.349 15.870
> 0.246
> So my client is running exactly as If it was in client server mode wich
> is not normal... when I use ethereal for monitoring what's going on, It
> confirms what I think... First, the server send a multicast packet, the
> client receives it but don't answer to the server... in fact, the
> client waits 64 second to send a packet to the server as if it was in
> client-server... and the, when four packets has been sent to the
> server, its run exactly like in the client server mode... the client
> polls the server depends on its poll intervall, and it's not the
> purpopse of multicast client wich should only send packet to server at
> the beginning for estimating parameters, and the only listening...
> anyone has idea?
>
It's hard to know exactly what version you are running, but please try
the RC1 version. There were a large number of problems with running
multicast with earlier versions. It may very well resolve your problem.
Danny
More information about the questions
mailing list