[ntp:questions] multicast configuration help

Danny Mayer mayer at ntp.isc.org
Thu Nov 23 20:08:51 UTC 2006


Collins wrote:
> Hello All-
> 
>  I'm trying to help some coworkers troubleshoot the following problem.
> 
> We have a NTP server and a client.  They work toghther fine in UNICAST
> mode.  When
> we try to run te client in multicast mode it works after ann intial
> echange(volley).  One of the things we are trying to do is get the
> client to listen only.  When we add novolley to the clinet ntp.conf
> file
> it does not form any assocations.
> 

Multicastclient doesn't have a novolley option. Only broadcastclient does.

> Can any one direct me as to how to get a client to listen to a
> multicast group address without sending any traffic?  I have attached
> the ntp.conf files for working and nono-working scenarios
> 
>   Thanks in advance
> 
>     Collins
> 
> client: (Does not work)
> broadcastclient 224.0.1.1 novolley

This is invalid. broadcastclient can only take one optional argument -
novolley. The server, is in any case, multicasting so this won't receive
packets anyway.

> restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
> disable auth
> driftfile /etc/ntp/drift
> broadcastdelay  0.008

Do you know why you put this in? Do you have a measure of broadcast delay?

> logfile /var/ntp.log
> 
> client:(works)
> multicastclient          224.0.1.1
> restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
> disable auth

This should prevent it sending extra traffic. If there is a burst
initially it's usually because it's trying to authenticate the server.
Once authenticated it only listens. In this case it is not even doing
that. You lose information about round-trip delay this way but that's
what the broadcastdelay option is about.

> driftfile /etc/ntp/drift
> broadcastdelay  0.008
> logfile /var/ntp.log
> 

This should work.

> server:
> restrict 124.101.91.221 nomodify notrap noquery
> server 127.127.1.0  #local clock
> broadcast 224.0.1.1 ttl 5 #key 1 ttl 5
> disable auth
> driftfile /etc/ntp/drift
> broadcastdelay  0.008
> authenticate no
> logfile /var/ntp.log
> keys            /etc/ntp/keys
> 
> This is the output when it does not work.
> # ntpq -np
> input_handler: fd=4 length 12 from 7f000001 127.0.0.1
> receive from 127.0.0.1
> in process_control()
> opcode 1, found command handler
> read_status: ID 0
> sendpkt(fd=4 127.0.0.1, 127.0.0.1, ttl=-6, 12)
> No association ID's returned

That's what you would expect as you are not receiving any broadcast packets.

Danny





More information about the questions mailing list