Kirill Plyashkevich created MESOS-9031:
------------------------------------------
Summary: 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
Affects Versions: 1.6.0
Reporter: Kirill Plyashkevich
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
- 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)
