Danny, I don't understand your problem. The reference ID for the server is unambiguous. As specified, it is the refetence ID of the reference clock (stratum 1) or source (remote) address/hash of the system peer (stratum > 1), however that is determined. It has nothing to do with the destination (local) address, whichever NIC is involved. You might be concerned about which local address to use as a client, but that is not an NTP issue. That's why the Autokey is so picky about knowing which one to use before launching the first packet.
Dave Danny Mayer wrote: > David L. Mills wrote: > >>Richard, >> >>Yes, you point out the second problem other than the IPv6 problem. The >>string you see usually applies to the local clock, or any other >>reference clock operated at a stratum other than one. Perhaps the most >>elegant solution is for the local clock driver to insert the IPv4 host >>address or IPv6 hash as the reference ID. >> > > > Which one? This has been one of my discussion issues over the years as > it relates to refids. You can have multiple addresses per NIC and > multiple NICs and then you have IPv4 and multiple IPv6 addresses. Which > do you choose. My answer has been that a system has one and only one > refid for all interfaces, packets, etc whether sent as a unicast > response, a multicast packet or a broadcast packet, none of which should > matter. > > Danny > _______________________________________________ > questions mailing list > [email protected] > https://lists.ntp.isc.org/mailman/listinfo/questions _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
