[ntp:questions] NTP over redundant peer links, undetected loops
davehart at gmail.com
Mon Feb 16 20:04:46 UTC 2009
On Feb 16, 8:56 am, "Maarten Wiltink" <maar... at kittensandcats.net>
> "Dave Hart" <daveh... at gmail.com> wrote in message
> > RFC1918 addresses are of course not globally unique, so are
> > particularly ill-suited to a reference ID used for loop detection.
> > Why play roulette if you have a globally unique IPv4 address to use
> > as a refid? ...
> You do? Lucky you. RFC1918 addresses are all I have, except for
> the one address on the outside of my modem, which of them all is the
> _least_ suitable because it's the one place in my network where I
> don't have, nor currently want, NTP service.
I said if. My original comment was if you're going to use a single
refid for the NTP host instead of using its interface address as refid
(meaning same server has different refid depending on which of its
interfaces you approach it via), prefer apparent unicast global IPv4
addresses over RFC1918 when selecting from several IPv4 addresses
which to use as refid. Which got Danny going again on his ntptrace
breaking spree saying refids are not IPv4 addresses and picking a
random number at startup is the wise way forward.
> RFC1918 addresses may not be globally unique, but they are also not
> routeable, so within any given network they _will_ be unique.
It is good to have a bit of lighthearted humor in these technical
> multi-homed hosts may seem to be a counter-example, living as they
> do on several networks at the same time, I think they still need
> unambiguous network addresses around them.
Sounds like a fine goal. Multi-homed hosts are more than a counter-
example, they were the very reason I suggested preferring non-RFC1918
when choosing a machine-wide ntpd refid, assuming as I was that one of
several IPv4 addresses would be used. Many servers, for example, have
a management network separate from their service access network. No
problem today running ntpd, but if you change ntpd to use the same
refid across all interfaces, choosing a likely-to-collide RFC1918
address isn't helping anyone.
On the nonroutability of RFC1918 addresses, have you ever seen someone
try to VPN back to their home network from a hotel network and fail
miserably because the hotel network and the home network have
conflicting ideas of how to route RFC1918 addresses? Personally, I'm
nearly irrational in my hatred for things that break end-to-end
communication, determined to avoid, disable, tame, or tunnel around
any packet manglers I'm saddled with.
More information about the questions