[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