1

I have the following setup for my docker swarm:

  • three Linux master nodes
  • one Linux slave nodes
  • Windows slave node

They are connected with an overlay network. Within the linux nodes everything works as expected.

But if I'm in a windows container(e.g. microsoft/nanoserver) and I try to ping a linux container with the internal dns name of the container. The DNS resolution works just fine, but the request times out. So far so bad. But it's getting stranger, because my linux container has two IP-addresses one is global loopback and another one which is in the same network.

Let's say the linux container has xx.xx.xx.2/32 as global lo and xx.xx.xx.3/24. The internal dns resolves to the ip xx.xx.xx.2. This cannot be pinged from windows containers. But the address xx.xx.xx.3 can be pinged. If I'm in a linux container, I can ping the xx.xx.xx.2 address. I also can curl the service(port 8080) of the windows container, within a linux container.

It's just weird. Has anyone experienced similar issues or can I manipulate the internal dns resolution of docker?

Also fun to note, it worked earlier. But after a swarm leave and join of the windows node it doesn't anymore.

Versions:

  • Windows Server 2016 - Docker version 17.06.2-ee-6, build e75fdb8
  • RedHat 7.4 (Maipo) - Docker version 17.12.0-ce, build c97c6d6

UPDATE: The windows node cannot reach a container which runs on the linux slave node all other containers can be pinged normally, but from the linux master nodes it is possible to ping the containers which run on the linux slave nodes.

Improve this question

1 Answer 1

Reset to default
1

I think Windows Server 2016 needs at least 17.09 Docker EE to support overlay networking and VIP's. I recommend updating it.

I was wrong, the latest version is indeed 17.06.2-ee-6 and should support overlay and VIP.

Second, ping isn't a good test, as it may not be available on the VIP or container IP depending on the setup (Docker has changed over time if the VIP does or does not respond to ping). I recommend using something that tests the Exposed container port, like curl. For testing you can just use something like bretfisher/netshoot which has common utilities like that installed.

Third, you could be resolving Swarm services on the network using the service name, not the internal hostname of containers. Depending on which network endpoint mode you use (VIP or DNSRR) in the service, this will resolve the correct VIP or the correct container IP for other containers on the same Docker network.

Also, you want a minimum of 3 manager nodes to follow raft consensus rules in a Swarm. 2 managers actually makes it less fault-tolerant then 1 manager.

Improve this answer
4
  • If I update docker with Install-Package -Name docker -ProviderName DockerProvider -Update -Force I get 17.06.2-ee-6. Also overlay networks should work it is listed if I type docker network ls
    – anstue
    Mar 12, 2018 at 8:02
  • Hmm, is IPv6 enabled on Windows (it needs to be). Can you curl a Linux nginx container from Windows? The availability of ping working in VIP's has been different across versions so I wouldn't rely on it as a connectivity test.
    – Bret Fisher
    Mar 12, 2018 at 17:26
  • Sadly there is no curl on windows, but I used the following with success: Invoke-RestMethod -UseBasicParsing -Uri 7e8574293552:8080, which is a nginx container. Updated Question and also master and slave setup.
    – anstue
    Mar 13, 2018 at 11:24
  • OK I updated my answer to ensure you're testing the networks in the way they are intended, and also corrected my statement about 17.06 vs. 17.09.
    – Bret Fisher
    Mar 13, 2018 at 18:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.