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

[Jan Engelhardt]

On Tuesday 2015-01-13 18:39, Tom Gundersen wrote:
>On Mon, Jan 12, 2015 at 12:55 AM, Jan Engelhardt <jengelh at inai.de> wrote:
>
>> 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)?

The bare metal (real) machine has configuration:
3: tapvbox0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP group default qlen 500
    link/ether 66:ba:7f:2d:8b:80 brd ff:ff:ff:ff:ff:ff
    inet 10.10.60.1/24 scope global tapvbox0
       valid_lft forever preferred_lft forever

VirtualBox services have been configured to bridge with that 
TAP interface. Inside a VBox *virtual* machine, there are the aforementioned
enp0s3 and brg0 (10.10.60.129/24) interfaces.

> 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
> 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 10.10.60.129/24 brd 10.10.60.255 scope global brg0

The virtual machine only receives L2 frames destined for 08:00:27:0a:c5:b2
(and broadcast), even when enp0s3 is in promisc mode.
This may very well be an artifact of TAP, or of how the VirtualBox
service processes on the real machine react to packets appearing
on the TAP fd and (not) feeding them to the VM...

>How can I reproduce this (in my test
>(using nspawn with --network-bridge) the bridge device is reachable

...as such, I do not think you will be able to reproduce with nspawn.
Perhaps KVM+TAP won't exhibit the behavior either.


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

Indeed. (It shows that I never tried, nor needed, bridges inside VMs.
Just on real ones ;-)