On 8/7/20 4:44 PM, Marc Roos wrote:
+-------------------------+ | HOST | | | | 192.168.10.20 | | | | | |+-----------------------+| || netns || ||+--------+ +----------+|| ||| eth0 | | eth1 ||| |||10.0.0.8| |172.16.1.5||| ||+--------+ +----------+|| |+-----------------------+| +-------------------------+The host is having some tunnels and interfaces that facilitate the network connections in the namespace via a macvtap as eth0/eth1.
Does that mean that (test)eth0 and (test)eth1 inside the "netns" network namespace are MACVTAP interfaces?
Do (test)eth0 and (test)eth1 both have the same parent interface? Is that host's parent interface what has 192.168.10.20 bound to it?Could you add 10.0.0.20 and 172.16.1.20 to the host's parent interface in addition to 192.168.10.20?
The reason why I have multiple networks is that for 'backend' tasks I only need an internal network. Internet facing tasks will mostly have public network connection and private network connection.
I'm not sure what to make of the "... and private network connection." bit. The rest makes sense to me.
I am testing with the CO mesos. Mesos destroys the task if the connection with any of its networks is lost.
Okay. I don't know what implications that has on things. But I'll try to move forward anyway.
So the first thing I need to realize, is make sure communication between the host and eth0 / eth1 are ok.
Okay. That's understandable.
To realize this I am doing this: On the host: ip route add 172.16.1.5/32 dev int1cnivtap ip route add 10.0.0.8/32 dev tun1cnivtap
Why are you using device routes instead of IP routes (via <IP>)?Is it because you don't have common subnets between the host and the network namespace?
In the namespace: ip route add 192.168.10.20 dev eth1 scope global table 81 ip rule add from all to 172.16.1.5 table 81 ip rule add from 172.16.1.5 table 81 ip route add 192.168.10.20 dev eth1 scope global table 82 ip rule add from all to 10.0.0.8 table 82 ip rule add from 10.0.0.8 table 82
-=FLAG ON THE PLAY=- You've got the same interface (eth1) in both of those sets of rules & routes. (I don't know if this is an artifact in the email or your actual config.
I think what you're trying to do is use different routing tables based on the incoming interface.
What I don't get is /why/ you are wanting to do that.
I think I already tested this. Or I at least do not know how to do this properly. These test should not fail.ping -I eth0 192.168.10.20 ping -I eth1 192.168.10.20
If you have proper routes, this should work without any problem.I'm guessing that you are wanting to use different routing tables to ensure that replies go back out the same interface that they came in. But I question if that's strictly necessary as I wonder if an asymmetric route would suffice.
I feel like adding IPs to the host's parent interface; e.g. 10.0.0.20 and 172.16.1.20, would greatly simplify things and allow normal routing to do it's thing without any help.
Is there a reason to /not/ add these (or comparable) IPs to the host's parent interface?
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
