moby: Cannot connect container by its overlay network IP from host
Description of problem: I create an overlay network and connect a container to it. I can ping the host IP from the container successfully. But it fails when I ping the container’s IP which the overlay network assigned to it. Do I need to make more settings for the connectivity, or is that a bug or a designed behavior?
docker version
Client:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:12:04 UTC 2015
OS/Arch: linux/amd64
Server:
Version: 1.9.1
API version: 1.21
Go version: go1.4.2
Git commit: a34a1d5
Built: Fri Nov 20 13:12:04 UTC 2015
OS/Arch: linux/amd64
docker info
Containers: 3
Images: 30
Server Version: 1.9.1
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 43
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.0-25-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 4
Total Memory: 3.86 GiB
Name: user11
ID: I5MJ:ANLS:EUGF:H7FV:4E3K:3KOJ:L4CD:P6LF:V3HD:AWXT:YL5E:23TJ
WARNING: No swap limit support
Cluster store: etcd://192.168.122.10:4001
Cluster advertise: 192.168.122.11:2376
uname -a
Linux user11 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Steps:
- Create an overlay network net1 10.10.11.0/24
- Create a container con11
- Connect con11 to net1, the IP 10.10.11.1 is assigned to con11
- Ping the host’s IP from con11 and ping the con11’s 10.10.11.1 from host.
Expected: ping of both direction in step 4 is successful.
Actual Results: Ping the host’s IP from con11 successfully. Ping the con11’s 10.10.11.1 from host failed.
About this issue
- Original URL
- State: open
- Created 9 years ago
- Reactions: 2
- Comments: 26 (10 by maintainers)
@zhaoxpZTE this is expected. Containers in overlay networks are fully isolated from being accessed from external networks (including host).
But these containers are by default given a way to reach externally via a special
docker_gwbridgenetwork which enables access to external network (including the host). Since these containers are also connected to thedocker_gwbridgenetwork, one can access the container via the interface connected to thedocker_gwbridgenetwork (which is eth1 inside the container).So, instead of trying to reach the container using 10.x.x.x (assigned to eth0). Check for the IP assigned to the eth1 of the container and you can access it from the Host.
@brugnara Yes, docker inspect doesn’t show the IP of the end point connected to
docker_gwbridge. I think we should show it. Please file an issue in docker/libnetwork.One workaround you can try is to get it from
docker network inspect docker_gwbridge.@ipa-srd-rd this post may be helpful; https://forums.docker.com/t/how-to-check-the-network-namespace-with-overlay-networking/12395/3 (also https://www.slideshare.net/MadhuVenugopal2/dcus17-docker-networking-deep-dive, and http://techblog.d2-si.eu/2017/05/09/deep-dive-into-docker-overlay-networks-part-2.html)
Sorry for that but I didn’t find a solution after days of searching and multiple posts in different forums. Also I guess it isn’t that unrelated to the overall topic in this ticket, although I am indeed aware of the fact that this is not generally the right way.
The communication within the overlay network works perfectly fine (I guess that’s what the ports are for?!). Just the communication between a host and a container/service on another host doesn’t work because the host itself is not part of the overlay network and, as I assume, has therefore no way to contact distant nodes in the overlay network. I am searching for a different way to contact such a container/service.
The workaround :
route add -net 10.0.9.0/24 dev docker_gwbridgeI think I had closed this issue by mistake, sorry. Reopen for keeping track of this. @josegonzalez
Was this ever implemented? I know the original poster closed the issue, but docker/libnetwork#1082 is still open, so I assume this was not implemented either.
@mavenugo think we should improve the documentation around that?