[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: MAC address of bridge interfaces



Steve McIntyre <steve@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


Reply to: