networkd: bridge MAC addresses are not inherited from physical interface

For what it's worth, I understand that the actual bug is not in netplan, but I think it would be nice to make things consistent across renderers by working around this in netplan.

It appears that the .netdev file can accept the MAC address value:

[NetDev]
Name=br0
Kind=bridge
MACAddress=01:23:45:67:89:AB

If you specify the macaddress in your yaml, this should work:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      match:
        name: ens3
  bridges:
    br0:
      macaddress: 00:11:22:33:44:55
      interfaces: [ens3]
      dhcp4: true

The renderer of the netplan.yaml likely knows this information and can provide it.

I think that having to provide the MAC is redundant and unnecessary.

MAAS, for example, can easily provide the MAC (and already does in many cases, at least for the v1 YAML).

When rendering the YAML in non-MAAS use cases, such as when configuring a LXD container in a script[1], the writer might be able to get the MAC address somehow, but it would be an extra step that would hurt the user experience.

[1]:
# Example of creating a LXC container with a Netplan configuration passed through cloud-init.
lxc init ubuntu:b $CONTAINER -s default --no-profiles
lxc network attach $BRIDGE $CONTAINER eth0 eth0
lxc config set $CONTAINER user.network-config "version: 2
ethernets:
  eth0:
    match:
      name: eth0
bridges:
  br0:
    interfaces: [eth0]
    addresses:
     - 172.16.99.20/24
    nameservers:
      addresses: [172.16.99.22]
    routes:
     - to: 0.0.0.0/0
       via: 172.16.99.22
       metric: 50
"

It looks like this is a limitation of networkd - I can't find anything in the docs or with google that would enable you to inherit a MAC. Looping in systemd devs for their thoughts.

For the purposes of this bug, I wonder if we could just preserve the "stable but random" behavior for virtual bridges, but if netplan knows that the bridge ultimately contains an Ethernet interface (possibly via a bond) we could simply use its MAC as the stable MAC by default. That way no change in behavior from networkd is required.

So in practice, the "random" mac address is not so random. I have a configuration where I'm deploying a set of machines in the same network, where each device has a br0 internally. Turns out, I often get matching "random" mac addresses across my machines, causing a conflict.

Fixing the mac after it's messed up is not possible over SSH, because my connection keeps dropping. The old behavior of using the eth0 mac address, or a random mac address that is random enough to prevent collisions would be much better.

The same proble with the bonding interfaces

setting the `macaddress` of the bridge doesn't work for me on 18.04

Same here, `macaddress` of the bridge doesn't work for me on 18.04

Edit : macaddress settings need a reboot, (I tried to netplan generate/apply, restart systemd-networkd ) ...

I experienced this issue as well which was a problem for me in dual booting scenarios (a random MAC on br0 under Linux and then the native MAC under Windows). I originally had a static lease configured and couldn't understand why I would get a different IP randomly. Then I realized this is exactly what was happening. I added the native macaddress to my br0 interface and rebooted. It worked! Thanks!

Edit: I should have posted my OS version. I am using Linux Mint 19 (Tara) which is based on Ubuntu Bionic.

The default behavior should be inheriting from one of the physical interfaces. I can confirm under RHEL7.

This wishlist report is, at least should be, outdated.

I acknowledge the "this used to work" ( and even "works that way on Red Hat Enterprise Linux Seven" )

It is fairly strange (stupid?) to create a new network device (the bridge) with identity (MAC-address) stolen from one of the underlaying members (the interfaces to be bridged).

If the actual question / wish is "I want a predictable MAC-address on brigde"
that can be done. Example /etc/systemd/network/10-netplan-mybridge.netdev
----8<---8<---8<----
[NetDev]
Name=mybridge
Kind=bridge
MACAddress=aa:d1:1e:25:e2:e7

[Bridge]
DefaultPVID=42
VLANFiltering=yes
----8<---8<---8<----

Nope, current netplan.io has yet no support for such bridge paramater.

Please see this kernel commit message for the reason setting the bridge MAC address was even possible in the first place (yes, it was for the cloning use case):
https://lists.linuxfoundation.org/pipermail/bridge/2008-March/005739.html

Is there any indication of how the "random" MAC address is generated, or where it's cached?

I have a prepared VM image, which I've cleaned as carefully as possible, using "virt-sysprep", and inside the image running "cloud-init clean --logs --seed"

However when I start multiple instances of it, the bridges get the same MAC address:

$ sudo arping 192.168.122.10
ARPING 192.168.122.10
42 bytes from 5a:ed:f7:c4:10:14 (192.168.122.10): index=0 time=1.495 msec
42 bytes from 5a:ed:f7:c4:10:14 (192.168.122.10): index=1 time=903.675 usec
^C
--- 192.168.122.10 statistics ---
2 packets transmitted, 2 packets received, 0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.904/1.200/1.495/0.296 ms

$ sudo arping 192.168.122.20
ARPING 192.168.122.20
42 bytes from 5a:ed:f7:c4:10:14 (192.168.122.20): index=0 time=912.481 usec
42 bytes from 5a:ed:f7:c4:10:14 (192.168.122.20): index=1 time=747.873 usec
^C
--- 192.168.122.20 statistics ---
2 packets transmitted, 2 packets received, 0% unanswered (0 extra)
rtt min/avg/max/std-dev = 0.748/0.830/0.912/0.082 ms

Workaround: separate cloud-init scripts for each one, assigning a MAC address

> Is there any indication of how the "random" MAC address is generated, or where it's cached?

I think this behavior is controlled by MACAddressPolicy= option in systemd
https://www.freedesktop.org/software/systemd/man/systemd.link.html#MACAddressPolicy=

You can also specify the policy by default:
https://www.freedesktop.org/software/systemd/man/systemd.link.html#Examples

This is causing me a nightmare on Hetzner with bridged KVM networking - the host machine (18.04 LTS Server) is "leaking" these arbitrary MAC addresses to the outside world and Hetzner is not happy obviously.

reading the above comments I am not clear if I can, or can not, set the MAC address of the bridge so it is the same as the host? If this is possible could someone show me an example please?

@theopensourcerer: Comment #2 shows how to set a MAC address on a Netplan interface:
https://bugs.launchpad.net/netplan/+bug/1782221/comments/2

You must delete the interface before running `netplan apply` for the setting to take effect. If your interface is `br0`, run `ip link delete br0 ; netplan apply`.

Note that a reboot is NOT required; what matters is deleting the affected interface so that Netplan can properly recreate it.

I wrote an example here: https://superuser.com/a/1389344/83694

@kvaps I had the same issue on Ubuntu 20.04 the default behavior was that the bridge gets the interface mac but on 22.04 was generating new one !

I changed the `MACAddressPolicy` from `persistent` to `none` and indeed the behavior reverted to cloning the interface mac.

But I noticed the default config in both Ubuntu versions was `MACAddressPolicy=persistent` I do not understand why on 20.04 it inherits the mac from the first attached interface although the config persistent should make it generate a new one !