1
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
That's the default on Linux: when creating a bridge and not setting its MAC address, by default the first enslaved interface will "transmit" its MAC address to the bridge and replace the previously randomly generated MAC. If the bridge's MAC is set before or after enslaving the first interface, the manual setting will stick instead. – A.B – 2019-12-28T15:15:13.053