Skip to main content
Unix & Linux

Return to Answer

more information, some reordering and added an answer to the question
Source Link
A.B
A.B
  • 39.6k
  • 2
  • 88
  • 134

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 theThe relation between this valuemachine-id and the way the bridge "stable random""stable" MAC address is generated is mentioned in the patch having implemented the (quite breaking) change:

=== This patch

This patch means that we will set a "stable" MAC for pretty much any virtual device by default, where "stable" means keyed off the machine-id and interface name.

It was also mentioned that this would be having impacts , but this was shrugged off.

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.

I could witnessverify that the same bridge name would get a different "stable random" value after doing the operations described in aboveDebian's link:

UPDATE Conclusion: this

Because the bridge MAC address is not limited to interfacesnow manually set the bridge won't inherit anymore one of typethe MAC addresses of other interfaces set as bridge ports, including the usual permanent bridge but(physical or VM's) interfaces which are expected to any interface that would generatehave each a random MACdifferent MAC address: for example types. Two systems using the same vethmachine-id, and the same bridge name macvlan(eg: tuntapbr0 are also affected.

But) with such bridge participating in routing because its MAC address is manually set the bridge won't inherit anymore the MAC address of other interfaces set as its(ie: there's an IP address configured on the bridge ports, but even if not the bridge can emit other frames related to bridging depending on its settings) on the same LAN will emit frames with the same source MAC address (bridge's), possibly disrupting switches in the path and anyway ignoring such systemssame source MAC address from the peer.

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:

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.

Each machine should have a different value. This is especially important for cloned VMs from a base template. The relation between machine-id and the way the bridge "stable" MAC address is generated is mentioned in the patch having implemented the (quite breaking) change:

=== This patch

This patch means that we will set a "stable" MAC for pretty much any virtual device by default, where "stable" means keyed off the machine-id and interface name.

It was also mentioned that this would be having impacts , but this was shrugged off.

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.

I could verify that the same bridge name would get a different "stable random" value after doing the operations described in Debian's link:

Conclusion:

Because the bridge MAC address is now manually set the bridge won't inherit anymore one of the MAC addresses of other interfaces set as bridge ports, including the usual permanent (physical or VM's) interfaces which are expected to have each a different MAC address. Two systems using the same machine-id and the same bridge name (eg: br0) with such bridge participating in routing (ie: there's an IP address configured on the bridge, but even if not the bridge can emit other frames related to bridging depending on its settings) on the same LAN will emit frames with the same source MAC address (bridge's), possibly disrupting switches in the path and anyway ignoring such same source MAC address from the peer.

the bridge MAC doesn't depend anymore on the bridge ports thanks to/because of this systemd behavior.
Source Link
A.B
A.B
  • 39.6k
  • 2
  • 88
  • 134

Browsing in Internet I found this bug report on systemd-udevsystemd-udev related to Debian 11 bridges: systemd-udev interferes with MAC addresses of interfaces it's not supposed to do #21185:

You can see how the MAC address initially random is oerwrittenoverwritten to a fixed one, twice to the same value for a given bridge name.

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.

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:

You can see how the MAC address initially random is oerwritten to a fixed one, twice to the same value for a given bridge name.

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:

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.

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.

Source Link
A.B
A.B
  • 39.6k
  • 2
  • 88
  • 134

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 oerwritten 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