I���m catching up on old mail and I notice this hasn���t been fixed yet.
The NTP protocol is designed to cope with failures without this sort of re-mapping. By re-mapping ntp2 on to ntp3, you have doubled the influence that ntp3 has, so that if someone has both ntp2 and ntp3 configured (which is a reasonable assumption) and ntp3 starts giving out bad data, things are more likely to break in some situations.
We have had discussion on this list before about the architecture of this, and so I hope others have taken my advice and are running at least 4 NTP servers (ie. the
ntp.net.nz 3 + 1(+) others, perhaps).
If people are running with only the
ntp.net.nz time servers, the impact of bad data is reduced if it bad data on ntp1, but increased if it is on ntp3.
I have just done some quick analysis, and ntpd treats named peers that resolve to the same IP addresses are distinct peers - I have a process running here that has selected the ntp2 entry as the system peer, and ntp1 and ntp3 are candidates. This means that it is averaging the three of them, and of course ntp2 and ntp3 are going to give me the same data so the average is weighted in their favour.
In any case, let���s not futs with the protocol and try outsmart it, it���s got redundancy built in, so lets use it - please remove the ntp2 -> ntp3 mapping, or, point ntp2 to somewhere other than ntp3.. though, if you point it to somewhere that people rely on as their 4th(+) server, you���re only slightly improving things.