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 connect                                                                                                                                                             ed to eachother via
an external network definition.


see also:
moby github discussion: https://github.com/moby/moby/discussions/52740

Reproduce the issue:
I have not found a way yet how to do it. but i do have a system that has
the issue now that can receive debugging work since it is non-prod.

Next steps:
As I mentioned in the moby discussion: I am considering to move to
static ip configurations on docker networks where this issue occurs and
am willing to keep posting results here.

Any remarks / recommendations from your side ?
It would really be nice to find root cause of this issue..

thanks in advance
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