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 <mlichvar@xxxxxxxxxx>
Date: Thursday, July 21, 2022 at 3:27 AM
To: chrony-users@xxxxxxxxxxxxxxxxxxxx <chrony-users@xxxxxxxxxxxxxxxxxxxx>
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 chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.