Re: NTP multicast client appears to work in unicast...



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@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
_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions

.