networkd: bridge MAC addresses are not inherited from physical interface

Bug #1782221 reported by Mike Pontillo
134
This bug affects 30 people
Affects Status Importance Assigned to Milestone
netplan
New
Undecided
Unassigned
systemd
New
Undecided
Unassigned

Bug Description

When configuring a software bridge (as I understand it), the default behavior in the Linux kernel (and, thus, also Ubuntu releases) has been to to inherit the MAC address of one of the physical interfaces associated with the bridge. (possibly the lowest-numbered MAC, for consistency.)

When testing Ubuntu 18.04, I configured a bridge in the following way:

"""
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      match:
        name: ens3
  bridges:
    br0:
      interfaces: [ens3]
      dhcp4: true
"""

I expected the bridge to inherit the MAC address associated with `ens3`, given that was the default behavior in previous Ubuntu releases. However, a random MAC address was generated. (I noticed this when the DHCP server provided a different IP address, but I'm not positive that was related, given that a different client identifier could have been used.)

Given this configuration, since all layer 3 traffic associated with the bridged interface can only come from the bridge, I would expect (for the purposes of ensuring MAC address uniqueness) the previous behavior of inheriting the MAC address from the physical interface should have been preserved.

I understand that networkd's default is to randomly generate the MAC address, but (given that many things on the network may break if a duplicate MAC is generated) I believe it would be more reliable to preserve the previous behavior of inherting the MAC from the physical interface instead.

summary: - Bridge MAC addresses are not inherited from physical interface
+ networkd: bridge MAC addresses are not inherited from physical interface
Revision history for this message
Mike Pontillo (mpontillo) wrote :

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.

Revision history for this message
Ryan Harper (raharper) wrote :

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.

Changed in netplan:
status: New → Incomplete
Revision history for this message
Mike Pontillo (mpontillo) wrote :

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
"

Changed in netplan:
status: Incomplete → New
Revision history for this message
Daniel Axtens (daxtens) wrote :

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.

Revision history for this message
Mike Pontillo (mpontillo) wrote :

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.

Revision history for this message
Atif Mahmood (atif1996) wrote :

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.

Revision history for this message
kvaps (kvapss) wrote :

The same proble with the bonding interfaces

Revision history for this message
Alejandro Mery (amery) wrote :

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

Revision history for this message
Poil (poil) wrote :

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

Revision history for this message
Poil (poil) wrote :

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

Revision history for this message
TitaniumCoder477 (tc477) wrote :

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!

Revision history for this message
TitaniumCoder477 (tc477) wrote :

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

Revision history for this message
Chong An (anch2150) wrote :

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

Revision history for this message
Geert Stappers (stappers-debian) wrote :

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.

Revision history for this message
Ryan C. Underwood (nemesis-icequake) wrote :

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

Revision history for this message
Brian Candler (b-candler) wrote :

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

Revision history for this message
kvaps (kvaps) wrote :

> 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

Revision history for this message
Alan Lord (theopensourcerer) wrote :

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?

Revision history for this message
Deltik (deltik) wrote :

@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

Revision history for this message
Mohammed Boukhalfa (mboukhalfa) wrote (last edit ):

@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 !

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers