Docker Engine 29.7 breaks Swarm overlay services on hosts without an IPv6 stack

A developer report on dev.to says Docker Engine 29.7 introduced a regression that leaves every Swarm service attached to an overlay network with zero running tasks on hosts that have no IPv6 stack. The break persists through 29.8.2, the newest static build available from download.docker.com at the time of writing.

The author, writing under the handle alexgeorgiev17, was not looking for the bug. They had built a test rig to benchmark a minor 29.8.0 changelog entry about spreading out the daemon's periodic overlay-network gossip, and before measuring anything, every overlay-attached service created on 29.8.2 came up with 0 running tasks instead of the requested replicas.

Zero replicas, same command

On Engine 29.6.2 the baseline behaved: a request for twenty replicas of an Alpine container sleeping on an overlay network produced 20/20 running tasks, and the author exec'd into containers and pinged across the overlay to confirm real traffic was flowing over the VXLAN tunnel. On 29.8.2 the identical command sequence, on the same host and image, returned 0/5, with docker service ps naming the reason: "network sandbox join failed ... overlay: cannot determine address family of transport: the local data-plane address is not currently known".

To compare releases directly rather than from memory, the author ran each engine — 29.6.2, 29.7.0, 29.7.2 and 29.8.2 — as its own dockerd with its own data directory and Unix socket. The results narrow the break cleanly: 29.6.2 works; 29.7.0, 29.7.2 and 29.8.0 through 29.8.2 all fail with the same error. The regression is therefore not new in 29.8 — it landed in 29.7.0, the release immediately after the last working one. The author did not bisect to a single commit, but notes that the official 29.7.0 and 29.8.0 release notes list several Swarm networking changes in that stretch, including one about service-mesh published ports sharing infrastructure with locally published ports, which touches the failing code path.

What it is not

Two plausible explanations were ruled out. A VXLAN port clash was the first suspect, since the side-by-side engines had been given different data-path ports, but rerunning 29.8.2 on the default UDP port 4789 with the older engine's overlay torn down reproduced the failure exactly. A general networking break was the second: a plain docker run of nginx with a published port worked fine on the same 29.8.2 install, so the bridge driver and the wider networking stack were healthy. The failure is specific to the Swarm overlay driver's VXLAN data plane.

The IPv6 correlation

The one property of the host that stands out is that it has no IPv6 stack at all — not disabled, simply absent, with /proc/sys/net/ipv6 and /proc/net/if_inet6 missing entirely. According to the post, 29.6.2 and the newer engines all log the same IPv6-related read failures at startup; the difference emerges when a container joins an overlay sandbox. 29.6.2 carries on and completes the join over IPv4, while 29.7.0 and later apparently ask something that comes back unanswered and treat that as fatal.

The author is explicit about the limits here: they did not read the overlay driver's source, so the absent IPv6 stack is a correlation rather than a proven cause, though the error text names address-family detection directly. Docker's own swarm networking documentation does not settle the question either way: it lists the ports hosts need open (2377 TCP, 7946 TCP/UDP and 4789 UDP for overlay traffic) and says nothing about IPv6 being required or excluded. By that documentation, the same test should have worked on 29.8.2 exactly as it did on 29.6.2.

No flag-level workaround

Creating the overlay network with docker network create -d overlay --ipv6=false did not help; the service still reported 0/5 with the identical error. Whatever goes wrong sits below the per-network IPv6 flag, and the author found no documented option that gets an IPv6-less host working again.

Why it matters

Operators running Swarm on hosts whose kernels are built without IPv6 — a niche but real category covering some trimmed virtual machines and minimal appliance images — could see every overlay-attached service stop scheduling a single task after an upgrade to 29.7 or later, with only a cryptic scheduler error to go on. Because Docker's documentation does not list IPv6 as a prerequisite, the change reads as an undocumented behavioural break rather than a shift in supported configurations. Until upstream confirms a cause, the practical takeaway from this report is to test the exact upgrade path on an IPv6-less host before rolling it out, and to keep 29.6.x pinned where the regression reproduces. It is a single firsthand account rather than an acknowledged Docker bug, so it is best treated as a strong caution while awaiting confirmation.