Introduction

When Flannel and Docker fail to start on the same host, the problem is usually not a mysterious double crash. It is typically a configuration conflict around networking, kernel settings, service ordering, or old cluster state. The fastest way to debug it is to stop guessing and check which daemon is failing first, what network ranges each component expects, and whether the host is actually set up for overlay networking.

Start with the service logs

Before changing any config, identify which service fails first and why.

1sudo systemctl status docker
2sudo systemctl status flanneld
3sudo journalctl -u docker -b
4sudo journalctl -u flanneld -b

This usually tells you whether the issue is:

• Docker failing to start at all
• Flannel failing to obtain subnet data
• networking setup failing after both daemons start
• an old state file or interface conflicting with the new config

Without this first step, the rest is guesswork.

Check for subnet overlap

A classic failure mode is overlapping network ranges between Docker's bridge network and Flannel's pod network. If Docker is using a subnet that overlaps the one Flannel wants to assign, route creation or bridge setup can fail.

Inspect the current Docker bridge range and the Flannel network config.

ip addr show docker0
cat /run/flannel/subnet.env
cat /etc/docker/daemon.json

If Docker and Flannel both try to occupy the same address space, choose non-overlapping CIDR ranges and restart them cleanly.

Verify IP forwarding and bridge networking settings

Overlay networking needs host kernel settings that are sometimes disabled on fresh machines or hardened images.

sysctl net.ipv4.ip_forward
sysctl net.bridge.bridge-nf-call-iptables

Typical settings are enabled like this:

sudo sysctl -w net.ipv4.ip_forward=1
sudo sysctl -w net.bridge.bridge-nf-call-iptables=1

Persist them in your sysctl config if this host is meant to stay part of a Kubernetes cluster.

Understand how Docker uses Flannel's subnet data

In older Docker-plus-Flannel setups, Flannel writes subnet information to /run/flannel/subnet.env, and Docker may rely on matching bridge configuration or startup options. If Flannel never writes that file, or Docker starts before the file exists, networking can come up incorrectly.

That is why service ordering matters. Flannel may need to initialize before Docker networking is fully configured, depending on the node setup.

Clean out stale interfaces and state carefully

If this host was previously part of another cluster or another CNI attempt, old interfaces and state can linger.

Typical leftovers include:

• 'docker0'
• 'flannel.1'
• stale CNI files under /var/lib/cni/
• old Docker network metadata

Do not delete these blindly on a production host, but on a broken test node it can be useful to inspect and reset the relevant network state before restarting services.

Remember that modern Kubernetes often uses containerd, not Docker

If you are following older Flannel guides, some of them assume Docker as the container runtime. Many newer Kubernetes environments use containerd instead. That means some Docker-specific troubleshooting advice may be irrelevant on modern clusters.

So confirm your actual runtime architecture first. If the node is supposed to use containerd, spending hours fixing Docker may be the wrong task entirely.

A minimal debugging sequence

A practical order looks like this:

1. check systemctl status and journalctl for both services
2. verify non-overlapping Docker and Flannel subnets
3. confirm kernel forwarding and bridge sysctls
4. inspect /run/flannel/subnet.env
5. restart services in a controlled order

Example restart sequence:

sudo systemctl restart flanneld
sudo systemctl restart docker

If Docker depends on Flannel-provided network state, restarting in the opposite order can preserve the failure.

Common Pitfalls

• Looking only at one daemon and not the logs from both Docker and Flannel.
• Letting Docker bridge networking overlap with Flannel's pod network CIDR.
• Forgetting kernel settings such as net.ipv4.ip_forward.
• Reusing a host with stale CNI or bridge state from an earlier cluster attempt.
• Following Docker-era Kubernetes advice on a node that is actually using containerd.

Summary

• Diagnose with service logs first so you know which component is really failing.
• Check for subnet overlap between Docker networking and Flannel networking.
• Ensure required host networking sysctls are enabled.
• Verify that Flannel writes the subnet state Docker expects.
• On modern Kubernetes setups, confirm whether Docker is even part of the intended runtime architecture.