Hi Grant!
> > 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.
>
>
I was just 'cleaning up' a bit an ubuntu server from unnecessary running processes. Now I have some external auth that is sometimes slow due to the fact that the external auth host has two ip addresses configured. One of those ip addresses is not reachable from my ubuntu server.
Do you know if there is currently something client side that actively addresses this issue of having applications assigned ip addresses on different networks?
I don't think I noticed this behaviour before my changes, could there be something smart in neworkmanager/systemd?
