Answers: <p><S>I think Windows Server 2016 needs at least 17.09 Docker EE to support overlay networking and VIP's. I <a href="https://docs.docker.com/install/windows/docker-ee/#update-docker-ee" rel="nofollow noreferrer">recommend updating it</a>.</s></p>
  
  <p>I was wrong, the latest version is indeed <code>17.06.2-ee-6</code> and should support overlay and VIP.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Also, you <a href="https://docs.docker.com/engine/swarm/admin_guide/#add-manager-nodes-for-fault-tolerance" rel="nofollow noreferrer">want a minimum of 3 manager nodes</a> to follow raft consensus rules in a Swarm. 2 managers actually makes it less fault-tolerant then 1 manager.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-03-12T08:02:20.443Z
Answers: 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`
Answers: anstue
Answers: CC BY-SA 3.0
Answers: 2018-03-12T17:26:02.383Z
Answers: 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.
Answers: Bret Fisher
Answers: CC BY-SA 3.0
Answers: 2018-03-13T11:24:57.827Z
Answers: Sadly there is no curl on windows, but I used the following with success: Invoke-RestMethod -UseBasicParsing -Uri  http://7e8574293552:8080, which is a nginx container. Updated Question and also master and slave setup.
Answers: anstue
Answers: CC BY-SA 3.0
Answers: 2018-03-13T18:42:50.620Z
Answers: 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.
Answers: Bret Fisher
Answers: CC BY-SA 3.0
Answers: 2018-03-05T22:13:34.260Z
Answers: 2018-03-13T18:42:17.850Z
Answers: 2018-03-13T18:42:17.850Z
Answers: Bret Fisher
Body: <p>I have the following setup for my docker swarm:</p>
  
  <ul>
  <li>three Linux master nodes</li>
  <li>one Linux slave nodes</li>
  <li>Windows slave node</li>
  </ul>
  
  <p>They are connected with an overlay network. Within the linux nodes everything works as expected.</p>
  
  <p>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. </p>
  
  <p>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.</p>
  
  <p>It's just weird. Has anyone experienced similar issues or can I manipulate the internal dns resolution of docker?</p>
  
  <p>Also fun to note, it worked earlier. But after a swarm leave and join of the windows node it doesn't anymore.</p>
  
  <p>Versions:</p>
  
  <ul>
  <li>Windows Server 2016 - Docker version 17.06.2-ee-6, build e75fdb8</li>
  <li>RedHat 7.4 (Maipo) - Docker version 17.12.0-ce, build c97c6d6</li>
  </ul>
  
  <p>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.</p>
  
Tags: <windows><linux><docker-swarm>
Title: Windows Docker in swarm with Linux nodes connection issue
UserDisplayName: anstue
ThreadText: # Windows Docker in swarm with Linux nodes connection issue
  
  (Asked by: username_0 on 2018-03-05)
  
  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.
  
  **Tags:** windows, linux, docker-swarm
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-03-05. Score: 1
  
  ~~I think Windows Server 2016 needs at least 17.09 Docker EE to support overlay networking and VIP's. I [recommend updating it](https://docs.docker.com/install/windows/docker-ee/#update-docker-ee).~~
  
  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 username_1/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](https://docs.docker.com/engine/swarm/admin_guide/#add-manager-nodes-for-fault-tolerance) to follow raft consensus rules in a Swarm. 2 managers actually makes it less fault-tolerant then 1 manager.
  
  > **Comments:**
  > **username_0**: 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`  
  > **username_1**: 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.  
  > **username_0**: Sadly there is no curl on windows, but I used the following with success: Invoke-RestMethod -UseBasicParsing -Uri  http://7e8574293552:8080, which is a nginx container. Updated Question and also master and slave setup.  
  > **username_1**: 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.  
  
  ---
  
  