Will there be any issue if I create a bridge in Linux with MAC address of its slave?

Question

In Windows if we create an external virtual switch in Hyper-V Manager, it will have the MAC address of the NIC that it is connected to.

So I want to do similar things in Linux, with systemd-networkd. My configuartion are as follows:

[tom@localhost ~]$ ls /etc/systemd/network/
br0.netdev  br0.network  enp3s0.network

[tom@localhost ~]$ cat /etc/systemd/network/br0.netdev 
[NetDev]
Name=br0
Kind=bridge
MACAddress=ac:22:0b:29:e6:0c

[tom@localhost ~]$ cat /etc/systemd/network/br0.network 
[Match]
Name=br0    
[Network]
DHCP=ipv4
IPv6AcceptRouterAdvertisements=no

[tom@localhost ~]$ cat /etc/systemd/network/enp3s0.network 
[Match]
Name=enp3s0    
[Network]
Bridge=br0
IPv6AcceptRouterAdvertisements=no

where ac:22:0b:29:e6:0c is the MAC address of only NIC in the system (which serves as the slave of br0).

Here is the outcome:

[tom@localhost ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::ae22:bff:fe29:e60c/64 scope link 
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global dynamic br0
       valid_lft 85622sec preferred_lft 85622sec
    inet6 fe80::ae22:bff:fe29:e60c/64 scope link 
       valid_lft forever preferred_lft forever

As you can see, now enp3s0 and br0 has the same link/ether and inet6 (link-local address).

So far it seems to have worked well. VMs created with qemu/kvm have working bridged network (with -net bridge -net nic, which makes use of qemu-bridge-helper). Both the host and the guests can connect to the Internet just fine.

However, I have a bit of doubt on whether such configuration can cause conflict at certain circumstances. So my question is, is this a right thing to do? Or is it a bad/ugly practice? If any, what will be the possible issues?

EDIT: Would there be any difference if I disable the link-local address of enp3s0 and/or make br0 accept ipv6 router advertisement?

[tom@localhost ~]$ ls /etc/systemd/network/
br0.netdev  br0.network  enp3s0.network

[tom@localhost ~]$ cat /etc/systemd/network/br0.netdev 
[NetDev]
Name=br0
Kind=bridge
MACAddress=ac:22:0b:29:e6:0c

[tom@localhost ~]$ cat /etc/systemd/network/br0.network 
[Match]
Name=br0
[Network]
DHCP=ipv4

[tom@localhost ~]$ cat /etc/systemd/network/enp3s0.network 
[Match]
Name=enp3s0
[Network]
LinkLocalAddressing=no
IPv6AcceptRouterAdvertisements=no
Bridge=br0

[tom@localhost ~]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:22:0b:29:e6:0c brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.111/24 brd 192.168.1.255 scope global dynamic br0
       valid_lft 86357sec preferred_lft 86357sec
    inet6 2404:c805:e00:5300:ae22:bff:fe29:e60c/64 scope global mngtmpaddr noprefixroute dynamic 
       valid_lft 1756sec preferred_lft 1756sec
    inet6 fe80::ae22:bff:fe29:e60c/64 scope link 
       valid_lft forever preferred_lft forever

Answer 1

It will generate a tremendous amount of ARP traffic and likely routing errors due to that config. TCP/IP is so robust that it takes significant degradation to usually be noticed by the user ( meaning person or the communicating processes).

ARP is the protocol in the Ethernet stack that lies just below IP. It stands for address resolution protocol and its role is to associate IP addresses with MAC addresses. There is no question it is degraded, but by design it will route packets even with ambiguity; using the value it last received. IPs are transitory sw assigned and can be assigned to different and distant devices nearly instantly - MACs are intended to be locked to hw and ARP uses that to determine which gateway gets the packet next.

So the answer is that it is already degrading your network. There are a few ways to prove this to yourself. There is something called an arpping- ping using the arp layer. It will drop packets. Send arpings to the two different ifaces at a high rate from an external source and look at the metrics.

Fire up wireshark and look at the ARP traffic while doing this and just in general.

Then fix the MAC. sudo ip link set dev interface address XX:XX:XX:XX:XX:XX With the new address hopefully being unique; if not unique, not local. On linux you can look at the ARP cache in the proc file system. A minimum check is that that mac isn't cached by your system.

You can also use things like iperf3 to test throughput. Setup multiple clients and or multiple servers on this lab routing through that bridge and Nic and look at the difference. If you do that please post results, just curious.

Rerun the same tests and look at the delta. If you do all this and the data indicates no difference id love to review it myself.

Worst case, I think, would be two identical Macs on the same WAN segment as the confusion would have enough non deterministic delay mixed in to allow some near deadlock conditions to occur. Thats speculation obviously.

And beyond all that, you are breaking a fundamental rule of 802.3 - MAC addresses are unique. Not they should be, or it would be nice if they were, but by definition they are. How you can you live with yourself?

Granted in embedded systems this gets broken all the time; but not when there is a routable path that does or could exist.