Dear Maintainer,
* What led up to the situation?
I encountered on some systems duplicate mac addreses for docker
containers.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Removing both containers (that are involved in the conflict) helps (workaround)
ENvironment where this occurs:
debian trixie, docker from debian (26.1.5)
docker compose from debian (2.26.1-4)
no static mac address or static ip address assignments in docker.
single host deployment / no docker swarm
containers are setup using multiple docker compose files; containers are connected to eachother via
an external network definition.
see also:
moby github discussion: https://github.com/moby/moby/discussions/52740
I have not found a common method to reproduce this issue, but luckily I
did find the issue on a testing system so I am capturing some debug
logs that I can attach to this bug report later on.
I would be very curious to what the cause of the issue is and what would
be recommended to do to handle this issue
thanks again.
tobias
merge 1138839 1138645 thanks Hi Tobias, Thank you for reporting this issue. The behavior you've encountered -- duplicate MAC addresses being assigned to containers on a bridge network -- is a known architectural quirk in older versions of Docker. In versions prior to 28.0, the Docker daemon (moby) derived a container's MAC address directly from its allocated IPv4 address. Under certain edge cases (such as rapid container recreation cycles, or interactions with third-party tools like Portainer), the IPAM allocator could race or reuse IPs in a way that resulted in duplicate MAC assignments on the bridge network. As noted by the maintainers in the upstream moby discussion you linked, they fundamentally resolved this starting in Docker 28.0 by dropping the IP-to-MAC derivation logic entirely. All container MAC addresses are now generated purely randomly. Since Debian has recently packaged the 28.5.x series, this bug is fixed in newer versions of the package (such as 28.5.2+dfsg1-1 and later). Once these newer versions migrate to Debian testing (Forky), this issue will be automatically resolved for you on that release. In the meantime, regarding your proposed workaround: yes, explicitly moving to static IP configurations on your Docker networks will prevent the IPAM allocator race conditions and is a solid workaround for the 26.1.5 branch in Trixie. I indeed do not feel comfortable backporting the upstream fix (https://github.com/moby/moby/pull/48808) to Trixie, as the changes are too invasive for a stable release. If you would like to try the newer version containing the fix immediately, I suggest using debian/testing, possibly in a VM. For now, I am merging your two reports and marking this as closed in the 28.x branch. Best regards, -rt
merge 1138839 1138645 thanks Hi Tobias, Thank you for reporting this issue. The behavior you've encountered -- duplicate MAC addresses being assigned to containers on a bridge network -- is a known architectural quirk in older versions of Docker. In versions prior to 28.0, the Docker daemon (moby) derived a container's MAC address directly from its allocated IPv4 address. Under certain edge cases (such as rapid container recreation cycles, or interactions with third-party tools like Portainer), the IPAM allocator could race or reuse IPs in a way that resulted in duplicate MAC assignments on the bridge network. As noted by the maintainers in the upstream moby discussion you linked, they fundamentally resolved this starting in Docker 28.0 by dropping the IP-to-MAC derivation logic entirely. All container MAC addresses are now generated purely randomly. Since Debian has recently packaged the 28.5.x series, this bug is fixed in newer versions of the package (such as 28.5.2+dfsg1-1 and later). Once these newer versions migrate to Debian testing (Forky), this issue will be automatically resolved for you on that release. In the meantime, regarding your proposed workaround: yes, explicitly moving to static IP configurations on your Docker networks will prevent the IPAM allocator race conditions and is a solid workaround for the 26.1.5 branch in Trixie. I indeed do not feel comfortable backporting the upstream fix (https://github.com/moby/moby/pull/48808) to Trixie, as the changes are too invasive for a stable release. If you would like to try the newer version containing the fix immediately, I suggest using debian/testing, possibly in a VM. For now, I am merging your two reports and marking this as closed in the 28.x branch. Best regards, -rt