NTP and Virtual IP

[Larry Barclay]

Our NTP model is to have one external NTP time source ( NTP Server ) feeding our HP Unix Service Guard cluster. For NTP Time server redundency we also use "local time clock" on two of the HP servers - all nodes are configured for peer mode as well. We have created a Service Guard package with a Virtual IP that external Windows/Linux clients can then use as a second NTP time server ( Again NTP Server redundency ): SG Package will float to any available server providing a common "Virtual" IP for NTP Service. Some windows based NTP clients have no problem with the Virtual IP. However, Microsoft W32Time can not handle the virtual IP. IP for NTP time request ( Virtual IP ) does not match IP for Time response ( Unix Server local IP ).
Question : Is there a HP Unix ntp/network patch that would have the NTP time packet respond with the same "Virtual" IP as in the client request ? Currently the NTP time packet coming from the Unix Host uses local IP, not the Virtual IP.

[melvyn burnard]

short answer is no.
You would need to recompile theapplication to respond with the virtual ip by making it bind to that ip address.

[A. Clay Stephenson]

As Melvyn indicated the answer is no; however, it should be possible to download and modify the source from http://gatekeep.cs.utah.edu/hppd/hpux/Networking/Admin/ntp-4.1.0b/ to serve as a replacement for xntpd - although this is not a trivial execrcise.

[rick jones]

NTP already has "HA" features built-in. In particular, a "proper" NTP client or (sub)server (and the HP-UX xntpd at least is such) should accept more than one NTP server IP in its configuration. (just like proper DNS resolver configs should have more than one DNS server specified...)

The NTP code will query the different servers, select the one it thinks is "best" and will remember the other in case connectivity to the one it selected is lost.

MC/ServiceGuard would seem to be overkill here.

[Bill Thorsteinson]

The recommended approach is three or more external sources. If you are using the local clocks, use the fudge parameter to raise their strata level so they don't win out over the external source. I have seen lots of ntp installations set to the local clock advertising stratum level 1 (highest reliability). Some even had the right day.