> >> +-------------------------+ >> | 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? In this case yes >Do (test)eth0 and (test)eth1 both have the same parent interface? In this case yes, but mostly not. I am actually having issues with using a macvtap of a gretap tunnel within the namespace. >Is that host's parent interface what has 192.168.10.20 bound to it? Yes >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? No I do not want to change the host to much. Furthermore I think it is more secure not having task ip ranges on the host. >> 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. Just ip ranges that do not have routing to the internet. >> 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? Yes >> 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. Yes sorry, copy typos, tables are of course for different eth. I like to be able to use any network in these containers. >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. How would this look like? >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 think the task will fail with an asymmetric routes. >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? > The host is more important than these tasks. I am having sort of hyper converged situation on storage servers. Keeping the host secure as in 'least exposed to tasks' is important to me. Also I would like to limit the changes needed on the host, to keep things simple there.
