Browsing in Internet I found this bug report on systemd-udev related to Debian 11 bridges: systemd-udev interferes with MAC addresses of interfaces it's not supposed to do #21185:
ash.in.ffho.net:~# for n in 0 1 2 3; do ip l add br$n type bridge; done ash.in.ffho.net:~# ip -br l br0 DOWN d2:9e:b3:32:53:42 <BROADCAST,MULTICAST> br1 DOWN e2:00:44:2c:5b:70 <BROADCAST,MULTICAST> br2 DOWN 0e:99:b7:42:f0:25 <BROADCAST,MULTICAST> br3 DOWN a6:3f:5f:b5:9a:d6 <BROADCAST,MULTICAST> ash.in.ffho.net:~# for n in 0 1 2 3; do ip link del br${n}; done ash.in.ffho.net:~# for n in 0 1 2 3; do ip l add br$n type bridge; done ash.in.ffho.net:~# ip -br l br0 DOWN d2:9e:b3:32:53:42 <BROADCAST,MULTICAST> br1 DOWN e2:00:44:2c:5b:70 <BROADCAST,MULTICAST> br2 DOWN 0e:99:b7:42:f0:25 <BROADCAST,MULTICAST> br3 DOWN a6:3f:5f:b5:9a:d6 <BROADCAST,MULTICAST>
As you can see, the bridges were created with low-level commands, but they always inherit the same MAC address value: a systemd component interferes and sets the MAC address. One can see this in action using ip monitor link:
22: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 0a:ae:c3:0d:ec:68 brd ff:ff:ff:ff:ff:ff 22: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff Deleted 22: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff 23: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 4e:e9:11:dd:a5:aa brd ff:ff:ff:ff:ff:ff 23: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff You can see how the MAC address initially random is overwritten to a fixed one, twice to the same value for a given bridge name.
An other side effect is that when interface is set administratively UP, the bridge operational status becomes DOWN instead of UNKNOWN initially because of this (see these answers of mine on SU and SF mentioning behaviors about DOWN and UNKNOWN: How does Linux determine the default MAC address of a bridge device? , linux ipv6 bridge address does not work when mac address is forced). Anyway this doesn't matter anymore once its first bridge port is attached.
Doing the same experiment inside a network namespace (eg: ip add netns experiment and ip netns exec experiment bash -l before running above commands twice) where systemd-udevd does not interfere will show the usual behavior of having different random addresses each time.
This is an effect of systemd ecosystem and doesn't happen on systems not running systemd (or older versions of systemd). One proposed fix is to use:
# /etc/systemd/network/90-bridge.link [Match] OriginalName=br* [Link] MACAddressPolicy=random
but it appears the real fix is to change the file that participates in generating this "stable random" value, as described there: https://wiki.debian.org/MachineId
Each machine should have a different value. This is especially important for cloned VMs from a base template. I didn't find a direct mention of the relation between this value and the way the bridge "stable random" MAC address is generated but could witness that the same bridge name would get a different "stable random" value after doing the operations described in above link:
rm -f /etc/machine-id /var/lib/dbus/machine-id dbus-uuidgen --ensure=/etc/machine-id dbus-uuidgen --ensure
giving now in previous ip monitor a new MAC address for the same bridge name: 32:ee:c8:92:9f:e8 instead of 1a:d0:fc:63:c1:71 when deleting and recreating brtest0.
Deleted 23: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 1a:d0:fc:63:c1:71 brd ff:ff:ff:ff:ff:ff 24: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether da:72:b6:63:23:e5 brd ff:ff:ff:ff:ff:ff 24: brtest0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default link/ether 32:ee:c8:92:9f:e8 brd ff:ff:ff:ff:ff:ff UPDATE: this is not limited to interfaces of type bridge but to any interface that would generate a random MAC address: for example types veth, macvlan tuntap are also affected.
But because its MAC address is manually set the bridge won't inherit anymore the MAC address of other interfaces set as its bridge ports on such systems.