On 2005-04-20, Srikanth K wrote:
> I am using multicastclient configuration option, but was unsuccessful.
> The two machines are configured in the following way:
>
> MACHINE 'A':
>
> '/etc/ntp.conf' entries:-
> server
You really should be using _at_ _least_ 3 remote time servers. 4, or
more, is even better; but I'm not going to cover that here. And you
ought to use 'iburst' on the server lines for faster initial sync with
the stratum1 server.
> keysdir /etc/ntp.keys
'keysdir ...' is used with autokey
Try this:
-----------------------------------8X-----------------------------------
driftfile /path/to/ntp.drift
server iburst
broadcast 224.0.1.1 key 1
keys /etc/ntp.keys
trustedkey 1
requestkey 1
-----------------------------------8X-----------------------------------
> '/etc/ntp.keys' entries:-
> 1 M pass
>
> MACHINE 'B':
>
> '/etc/ntp.conf' entries:-
Try this:
-----------------------------------8X-----------------------------------
driftfile /path/to/ntp.drift
multicastclient 224.0.1.1 key 1
keys /etc/ntp.keys
trustedkey 1
requestkey 1
-----------------------------------8X-----------------------------------
> /etc/ntp.keys:-
> 1 M pass
>
> Although 'B' was receiving packets from 'A' at regular intervals, but i
> couldn't find out from any of the query tools ( 'ntpq' or 'ntpdc').
>
> My Questions are:
>
> 1> What is the exact behavior expected from machines 'A' and 'B' with
> respect to 'broadcast 224.0.1.1' and 'multicastclient 224.0.1.1'
> configurations.
(glossing over some of the fine points ...)
A sends an NTP packet to the multicast address every 64 seconds. This
packet carries the timestamp for established multicast clients.
When B first receives a multicast packet from A, B initializes a
temporary unicast association with A. This unicast association is used
for the exchange of authentication credentials and delay calculations.
Once all the preparation is complete, the association changes from
unicast to multicast and B listens on the multicast address.
If you are using ntpq -p to monitor the status of B you will see the
following (I'll use one of my multicast clients which is only configured
to listen to one multicast server as an illustration):
* Immediately after starting ntpd on the client (before it receives the
first multicast packet):
# ntpq -p
No association ID's returned
* After the client receives the first multicast packet (note the 'u' in
the 't' column):
# ntpq -p
remote refid st t when poll reach delay offset jitter
===================================================================
*ntp0.kostecke.n .CHU2. 1 u - 64 1 0.636 0.764 0.196
* After the client and server exchange authentication credentials and
delay calculation packets _and_ the client receives the next multicast
packet (note the 'm' in the 't' column):
# ntpq -p
remote refid st t when poll reach delay offset jitter
===================================================================
*ntp0.kostecke.n .CHU2. 1 m 7 64 3 0.636 0.764 0.179
You can usually expect to see a multicast association established in ~70
to 128 seconds following client start-up.
> 2>Using any ntp query tools 'ntpq' or 'ntpdc', can i check the status of
> ntpd (with respect to multicastclient configuration) in machine 'B'. If
> so, kindly mention the interactive internal commands that can be used to.
For starters:
ntpq -p B --> will show you the peer status (i.e. who B is synced to)
ntpq -c as B --> will show you the authentication status of B
ntpq -c "rv 0 B" --> will show you the autokey certs held by B
> 3> How do i check that 'B' is actually updating its local clock with the
> broadcast packets from 224.0.1.1, considering that 'B' has selected 'A'
> for synch thru 224.0.1.1.
ntpq -p B
--
Steve Kostecke
NTP Public Services Project - http://ntp.isc.org/ |