Re: [EXTERNAL] Re: 答复: [chrony-users] about NT P services on multiple network interfaces.

We have clusters of Chrony NTP servers that respond on multiple virtual IP addresses (both v4 and v6). They are all configured as IPs on one logical interface in the OS (which itself is actually a bond). Chrony does need to “bind” to all as noted below, but it does indeed respond with the source IP matching the destination of the request, as long as it’s one of those IPs configured at the OS level. The tricky part is ensuring the system routing allows for the proper output (return) paths for all the addresses. We use policy-based routing heavily for this and it works well for multiple millions of clients.

--
Dan

From: Miroslav Lichvar <[email protected]>
Date: Thursday, July 21, 2022 at 3:27 AM
To: [email protected] <[email protected]>
Subject: [EXTERNAL] Re: 答复: [chrony-users] about NTP services on multiple network interfaces.
On Thu, Jul 21, 2022 at 01:54:12AM +0000, chengyechun wrote:
> Thank you for your reply；
> This is my expression problem. When I use chrony as the server, add bindaddress 0.0.0.0 to listen to all IPv4 addresses. This is fine. However, if a cluster needs time synchronization and a machine is used as the ingress of the cluster, it is a server inside the cluster and uses an IP address. If it is a client outside the cluster, can it use another IP address? This means that the IP addresses of the received and sent packets are different.

It's still not very clear to me what's the issue. Are you trying to
restrict access, or are some clients not working if bindaddress is
0.0.0.0?

As a server, chronyd follows bindaddress. As a client, it follows
bindacqaddress. They can be different. The default of 0.0.0.0 means it
listens on all addresses the host has. If you change it to a specific
address, it will not listen on other addresses.

As a server, it should always respond with the same address as it
received the request. NTP clients will not normally accept a response
from a different address than they sent request to, but bindaddress
shouldn't change anything about that.

--
Miroslav Lichvar


--
To unsubscribe email [email protected]
with "unsubscribe" in the subject.
For help email [email protected]
with "help" in the subject.
Trouble?  Email [email protected].