[systemd-devel] networkd-218 won't set bridge l2addr to slave device

Tom Gundersen teg at jklm.no
Tue Jan 13 09:39:07 PST 2015

Hi Jan,

On Mon, Jan 12, 2015 at 12:55 AM, Jan Engelhardt <jengelh at inai.de> wrote:
> When using the old-fashioned brctl to set up a bridge, it would give the
> bridge the L2 address of the first slave when the slave is added.
> networkd does not do that, which leads to a setup like this:
> 2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> master brg0 state UP group default qlen 1000
>     link/ether 08:00:27:0a:c5:b2 brd ff:ff:ff:ff:ff:ff
>     inet6 fe80::a00:27ff:fe0a:c5b2/64 scope link
>        valid_lft forever preferred_lft forever
> 3: brg0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UP group default
>     link/ether fa:ef:64:e8:77:d2 brd ff:ff:ff:ff:ff:ff
>     inet brd scope link brg0
>        valid_lft forever preferred_lft forever
>     inet brd scope global brg0
>        valid_lft forever preferred_lft forever

Yes, that is how it works now. The MAC address is guaranteed to always
stay the same for a given bridge, and not be affected by what slaves
are attached.

> tcpdump now tells us on ping:
> 66:ba:7f:2d:8b:80->ff:ff:ff:ff:ff:ff ethertype ARP (0x0806), length 44:
>         Request who-has tell, length 28
> fa:ef:64:e8:77:d2->66:ba:7f:2d:8b:80 ethertype ARP (0x0806), length 62:
>         Reply is-at fa:ef:64:e8:77:d2, length 46
> 66:ba:7f:2d:8b:80->fa:ef:64:e8:77:d2 ethertype IPv4 (0x0800), length 100:
> > ICMP echo request, id 22523, seq 1, length 64
> The problem is, the '129 machine never receives this, because the
> enp0s3 interface has a different L2addr and filters this. Setting
> promiscuous mode does not let it pass, probably because '129 is a
> VirtualBox environment. In any case, I do not think +PROMISC would be
> the right fix.

Hm, I thought the kernel would figure out the right thing here and set
PROMISC on enp0s3 if necessary. How can I reproduce this (in my test
(using nspawn with --network-bridge) the bridge device is reachable
from the containers just fine, which I thought would be the same as
your setup, but I guess not. What do you mean by '129 being a
VirtualBox environment? Is not brg0 set up by networkd, or do you mean
you are running all of this inside VirtualBox (and enp0s3 is a virtual

> Setting the L2addr of brg0 to that of enp0s3 makes ICMP echo
> exchangeable as expected. I think that networkd's default
> MACAddressPolicy= should not be "random" (nor "persistent"),
> but a new "slave".

This is not really nice, as it only really works reliably with one
slave device (which is not very useful). If you have more devices,
then whichever is the first to appear (which may be random) will
decide the MAC address. Moreover, you are not really solving the
problem, as all the ports that do not have the same MAC address as the
bridge will still be unable to forward packets...



More information about the systemd-devel mailing list