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

[Tom Gundersen]

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 169.254.69.103/16 brd 169.254.255.255 scope link brg0
>        valid_lft forever preferred_lft forever
>     inet 10.10.60.129/24 brd 10.10.60.255 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 10.10.60.129 tell 10.10.60.1, length 28
> fa:ef:64:e8:77:d2->66:ba:7f:2d:8b:80 ethertype ARP (0x0806), length 62:
>         Reply 10.10.60.129 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:
>         10.10.60.1 > 10.10.60.129: 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
device)?

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

Cheers,

Tom