[ https://issues.apache.org/jira/browse/MESOS-9031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533475#comment-16533475 ]
Qian Zhang edited comment on MESOS-9031 at 7/5/18 10:22 AM: ------------------------------------------------------------ [~Kirill P] It's weird, I think there should be no firewall issue in your environment since the default policy of your FORWARD chain is ACCEPT {quote}:FORWARD ACCEPT [146628:34388360] {quote} So no packets will be dropped by this chain. In my environment (a Ubuntu 17.10 VM), the default policy of the FORWARD chain is DROP, that's why I need to add that rule ("iptables -t filter -A FORWARD -o mesos-cni0 -j ACCEPT"). Can you please try another application rather than akka? E.g., launch a simple http server ("python -m SimpleHTTPServer 8080") to join a CNI bridge network and map its port to a host port, and then launch another container in the same CNI bridge network to access that http server via hostIP:hostPort, will it have the same timeout issue? was (Author: qianzhang): [~Kirill P] It's weird, I think there should be no firewall issue in your environment since the default policy of your FORWARD chain is ACCEPT {quote}:FORWARD ACCEPT [146628:34388360] {quote} So no packets will be dropped by this chain. In my environment (a Ubuntu 17.10 VM), the default policy of the FORWARD chain is DROP, that's why I need to add that rule ("iptables -t filter -A FORWARD -o mesos-cni0 -j ACCEPT"). > Mesos CNI portmap plugins' iptables rules doesn't allow connections via host > ip and port from the same bridge container network > ------------------------------------------------------------------------------------------------------------------------------- > > Key: MESOS-9031 > URL: https://issues.apache.org/jira/browse/MESOS-9031 > Project: Mesos > Issue Type: Bug > Components: cni, containerization > Affects Versions: 1.6.0 > Reporter: Kirill Plyashkevich > Assignee: Qian Zhang > Priority: Major > > using `mesos-cni-port-mapper` with folllowing config: > {noformat} > { > "name" : "dcos", > "type" : "mesos-cni-port-mapper", > "excludeDevices" : [], > "chain": "MESOS-CNI0-PORT-MAPPER", > "delegate": { > "type": "bridge", > "bridge": "mesos-cni0", > "isGateway": true, > "ipMasq": true, > "hairpinMode": true, > "ipam": { > "type": "host-local", > "ranges": [ > [{"subnet": "172.26.0.0/16"}] > ], > "routes": [ > {"dst": "0.0.0.0/0"} > ] > } > } > } > {noformat} > - 2 services running on the same mesos-slave using unified containerizer in > different tasks and communicating via host ip and host port > - connection timeouts due to iptables rules per container CNI-XXX chain > - actually timeouts are caused by > {noformat} > Chain CNI-XXX (1 references) > num target prot opt source destination > 1 ACCEPT all -- anywhere 172.26.0.0/16 /* name: > "dcos" id: "YYYY" */ > 2 MASQUERADE all -- anywhere !base-address.mcast.net/4 /* > name: "dcos" id: "YYYY" */ > {noformat} > rule #1 is executed and no masquerading happens. > there are multiple solutions: > - -simpliest and fastest one is not to add that ACCEPT- - NOT A SOLUTION. > it's happening in `bridge` plugin and `cni/portmap` shows that > snat/masquerade should be done during portmapping as well. > - perhaps, there's a better change in iptables rules that can fix it > - proper one (imho) is to finally implement cni spec 0.3.x in order to be > able to use chaining of plugins and use cni's `bridge` and `portmap` plugins > in chain (and get rid of mesos-cni-port-mapper completely eventually). -- This message was sent by Atlassian JIRA (v7.6.3#76005)