Steve McIntyre <st...@einval.com> writes:
> In my experience, the bridge may end up advertising the MAC of any/all
> of the underlying interfaces, and that behaviour can be racy
> sometimes. I noticed locally that *sometimes* I'd lose IPv6
> connectivity from my workstation when I started bridge VMs. Eventually
> I worked out that the MACs from the VMs were causing my bridge to
> change IP.
OK, for me Debian stretch worked reliable and stable in that the
bridge interface always got the MAC address of the physical eth0
interface which was added as bridge port immediately after bridge
creation. And it didn't change its MAC address when adding/removing
tap interfaces later, i.e. starting/stopping VMs.
I care about the MAC address, because I list all addresses in
/etc/ethers which I copy to most of my machines, I use them in DHCP
server configuration, and I also sometimes use MAC addresses in my
netfilter rules in my internet router.
With bullseye, the MAC address of the bridge changed. Since it seems
fixed across reboots, I could use this made-up address in all relevant
places. But I'd like to at least understand, where this address comes
from. It seems it is not from the kernel and not from the
bridge-util's brtcl(8) program: If have two VM's, both amd64, running
Debian buster and Debian bullseye, but with the exact same own-build
kernel Linux 5.16.1.
On both machines I did
# ip tuntap add mode tap
# brctl addbr br0
and get interface tap0 and br0 with MAC addresses that are somehow
invented. A difference is in the bridge ID, which seems to cause the
differnet behavior afterwards:
On buster, the bridge has an ID of 0
# ip tuntap add mode tap
# brctl addbr br0
# ip l
[...]
6: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 76:81:14:fd:07:b3 brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 46:50:88:4b:73:9c brd ff:ff:ff:ff:ff:ff
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no
On bullseye, the bridge's ID is the same as its MAC address
# ip tuntap add mode tap
# brctl addbr br0
# ip l
[...]
5: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 26:12:51:60:03:4e brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether ce:a7:4d:3e:6e:43 brd ff:ff:ff:ff:ff:ff
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.cea74d3e6e43 no
When I now add the tap interface as a bridge port, Debian buster
changes the bridge ID and MAC address to the MAC address of the tap
interface, bullseye does not:
On buster
# brctl addif br0 tap0
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.768114fd07b3 no tap0
# ip l show br0
7: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether 76:81:14:fd:07:b3 brd ff:ff:ff:ff:ff:ff
On bullseye
# brctl addif br0 tap0
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.cea74d3e6e43 no tap0
# ip l show br0
6: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT
group default qlen 1000
link/ether ce:a7:4d:3e:6e:43 brd ff:ff:ff:ff:ff:ff
Using strace, I see that both versions of brctl do exactly the same
and both kernels are also the same. So where and how does the bridge
interface get its ID and MAC address from? Is systemd/udevd involved?
> Now I've modified things:
>
> auto br0
> iface br0 inet dhcp
> hwaddress XX:XX:XX:XX:XX:XX
Anyway, thanks for the hint to hwaddress in /etc/network/interfaces.
I will do that, too.
Steve
