On 2/7/22 2:31 AM, Marc wrote:
I am testing a bit with containers and some of them I am giving multiple networks (just by adding interfaces on different networks).
Okay. I think I understand.
This way I can use the specific service on both networks.
I take this to mean that services A and B are on net10 while services B and C are on net122. Wherein services A and C are isolated to their own network with service B being available on both networks.
With some applications this seems to go fine. With others the 'wrong' ip address is being used, which results failed connection.
I would expect that the connections eventually connect. If they don't ever connect when they choose the wrong /initial/ address, that seems like a bug (in the application) to me.
Example: containter A has eth0 192.168.10.x/24 and eth1 192.168.122.x/24
ACK
When I ping this container from a vm only on the 192.168.10.x network. The 'first' ping fails (when 192.168.122.x is being resolved) the 2nd ping is ok because it resolves the 192.168.10.x ip
Are you saying the first invocation of the ping command or the first ping (ICMP) echo request packet? Assuming that you are sending multiple packets per command invocation, the former seems problematic to me. The latter falls under into the sub-optimal but likely acceptable category.
Question: is there some setting in linux that it automatically selects/prefers the 'routable' ip from a dns lookup?
I've never addressed this at the routing layer. Though I would expect that the /default/ route (or a destination network route) to suffice to allow fall back. -- Though there is a chance that the service running on 192.168.122.x to refuse to talk to clients on 192.168.10.x/24 network for various reasons. And vice versa for 192.168.122.x/24 network trying to talk to 192.168.10.x.
My first attempt at addressing this would be via DNS response ordering.I believe that the BIND (named) "options {...}" directive to do this is "sortlist {...}". Maybe something like the following:
options {
...
sortlist {
192.168.10.0/24; {
192.168.10.0/24;
192.168.122.0/24;
};
192.168.122.0/24; {
192.168.122.0/24;
192.168.10.0/24;
};
}
...
}
N.B. This is an untested hypothetical config based on memory and quick
reference of Zytrax's website [1] for syntax that I've not used in ~8 years.
The idea here is that the DNS server -- BIND (named) in this case -- alters the response that it gives to clients based on their source IP address. Thus clients in the 192.168.10.0/24 network are given superior 192.168.10.0/24 IP addresses before inferior 192.168.122.0/24 IP addresses. Similarly, clients in the 192.168.122.0/24 network are given superior 192.168.122.0/24 IP addresses before the inferior 192.168.10.0/24 IP addresses.
Question: is there a standard for applications to handling multiple returned A records. So if eg. 3 records are returned, all are being tested until a valid connection has been found?
I don't know. I would /expect/ that well behaved applications would try each of the IP addresses that they are given. At least within reason. Expecting an application to try double digits of IP addresses is probably unrealistic. But where is the line of realistic and unrealistic? That's situationally dependent. Some ... more questionable quality ... applications have problems with more than one IP. Some ... even more questionable quality ... applications have problems with any response that's not an IP, thus even a CNAME is a problem for them.
[1] DNS BIND9 Query Statements (Zytrax) - http://www.zytrax.com/books/dns/ch7/queries.html#sortlist
There may be some routing tricks that can be used to try to address this. But I would /definitely/ start with ... streamlining the information that is returned from the DNS server to them. E.g. avoid the problem entirely if possible.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
