Subject: Multicast NTP at high TTL?

From: [email-masked] (Bruce A. Mah)
Date: Tue, 23 Jun 1998 16:38:30 -0700

Hello--

I've been doing some testing of multicast NTP at my site.  In addition to 
packets from one of local time servers, which is configured to multicast to 
our local network, my multicast clients are also getting packets from over a 
dozen other time servers on the MBONE, apparently multicasting with extremely 
high TTLs.  (The servers I tcpdumped are sending one multicast packet every 64 
seconds.)

This seems like a bad idea to me, since this generates excess multicast 
traffic, in addition to the packets created when the clients actually try to 
synchronize to these (potentially far-off) servers.  I only want to 
synchronize to servers on my local network, so I'm restricting the clients to 
ignore anything non-local.

But...wouldn't it be better if NTP time servers only multicast with TTLs that 
would limit their packets to their "site"?

Thanks for any thoughts on this...

Bruce.

---

From: Ajit Thyagarajan <[email-masked]>
Date: Tue, 23 Jun 1998 21:55:44 -0400

>high TTLs.  (The servers I tcpdumped are sending one multicast packet every 64

The easiest solution is to configure your NTP clients to use a
multicast address that is different from the default (224.0.1.1).
Packets from the other servers should get pruned back.

>ignore anything non-local.

One pkt every 64 seconds is really not that much traffic!  In the
client-server mode, NTP clients increase the polling interval with the
servers to 15 mins or more.  In addition, there is a mode of operation
where you can just synchronize using the multicast packets received
(i.e. not try to synchronize with the advertising servers).  And
finally, if the client finds that the "remote" server does not provide
good time, it will remove it from its selection algorithms (in some
versions of NTP, it stops synchronizing with it as well).

>would limit their packets to their "site"?

Well, this is a choice made by the operators of NTP servers who want
to broadcast (ooops multicast) time.  There are some NTP clients
connected to the MBone that benefit from this as they don't have local
NTP servers.

Ajit

---

From: [email-masked] (Bruce A. Mah)
Date: Wed, 24 Jun 1998 08:21:58 -0700

If memory serves me right, Ajit Thyagarajan wrote:

> One pkt every 64 seconds is really not that much traffic!  

You're quite right.  It just seemed kind of odd that by default, my clients 
get data from time servers I don't care about and may not want to trust.  
Probably I'll filter out the off-site servers.

So it looks like the NTP algorithms "do the right thing", although I'm still 
learning about what exactly that is.  :-)

Thanks,

Bruce.

---

From: Hugh LaMaster <[email-masked]>
Date: Wed, 24 Jun 1998 12:32:05 -0700 (PDT)

> Probably I'll filter out the off-site servers.

Easy to do, but, I'm not sure it is necessary.

> learning about what exactly that is.  :-)

NTP is very smart about actually using particular sources.  
So, mostly, it is designed to be "the more sources the merrier".
So, under normal circumstances, I wouldn't worry about getting
time from a bad source or two.  Happens all the time, and ntp
is designed to select the correct sources.

My only complaint about the ntp multicasts is that in the past
people would sometimes set up to be a multicast ntp server not 
realizing what it entails to be an ntp server and with their 
routers misconfigured for such a role, sometimes resulting in
associated bogus garbage traffic, etc.  But, properly configured
multicast ntp servers are useful to have out there. 

--
 Hugh LaMaster, M/S 233-21,    ASCII Email: [email-masked]
 NASA Ames Research Center     Or:          [email-masked]
 Moffett Field, CA 94035-1000  No Junkmail: USC 18 section 2701
 Phone: 650/604-1056           Disclaimer:  Unofficial, personal *opinion*.