On Mon, Jan 22, 2018 at 5:14 AM, Jaime Caamaño Ruiz <jcaam...@suse.de> wrote:
> > - clean ip tables in B sudo iptables -F sudo iptables > > -t nat -FIn my testing cleaning the iptables in this way breaks the > > docker container's ability to route to the outside world so I would > > not recommend cleaning the iptables as this will make the container > > not be able to reach anything at all. > > A requirement of our test setup is that the docker container can reach > the builder with no nat'ing in between. By default docker network does > masquerading to the outside world and cleaning ip tables gets rid of > it. Is a rather rudimentary way of achieving it but worked for us. The > proper way to do it is by creating a separate docker network with the > option com.docker.network.bridge.enable_ip_masquerade disabled. > > Disable masquerading also requires adding a route in the builder back > to the docker network. Otherwise, as you say, there wont be > connectivity: > > route add -net <docker network> netmask <docker netmask> gw <docker host > ip> > > Worth mentioning is that this whole setup worked for us pre cloud > provider change. > After working with our cloud provider this morning we were able to resolve this with this patch https://git.opendaylight.org/gerrit/67436 to allow the docker IPs to be route-able rather than dropped by the network. This should allow your csit tests to communicate between hosts and containers now but let us know if there continues to be issues. For the record we used "ZZCI - CentOS 7 - docker - 20180110-1659" to test. I'm not sure which docker image you're using but you might want to switch to using one of the ZZCI ones moving forward. I can also confirm that even calling the 2 iptables -F commands won't break the routing with the patch above so you should be able to continue with your existing tests that do this. > We should be setting iptables -P FORWARD ACCEPT to allow another host > > to reach inside the docker container on the docker host however even > > after setting this things are still unrouteable. > > This is one more thing that docker did by default but no longer does. I > will crosscheck if it affects us but I dont think so. Our specific > problem is packets going out of the container towards the builder, > being forwarded in the docker host, but getting lost somewhere between > the docker host and the builder. > I can confirm that at least in my test environment I had to set this parameter. Regards, Thanh
_______________________________________________ sfc-dev mailing list sfc-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/sfc-dev
