1

I have a fresh install of Debian 11 and did a bridge setup:

  auto br0   
  iface br0 inet dhcp
    bridge_ports eno1

What I expect is that br0 has the same MAC address as eno1 but it gets a randomly generated one. I can fix the behaviour by manually assigning the MAC via hwaddress ether aa:bb:cc:dd:ee:ff but I don't understand the behaviour, on my other hosts I don't have to set the address manually. Why does that happen?

Improve this question

2 Answers 2

Reset to default
0

What I expect is that br0 has the same MAC address as eno1

And that expectation is wrong: Each port of the bridge has its own MAC address, different from all other addresses, and br0 is just the "internally" facing port.

Any hardware switch will have the same setup.

but it gets a randomly generated one

Exactly. Which is the right behaviour.

I can fix the behaviour by manually assigning the MAC

And if you assign the same MAC as eno1 to br0, you have just screwed up the spanning-tree algorithm, so make really really sure you never have loops or redundant connections in your network involving that bridge.

on my other hosts I don't have to set the address manually.

What other hosts are you talking about? And if their default behaviour is to have two bridge ports with the same MAC address, that behaviour is broken.

Improve this answer
4
  • Okay thats suprising to me. I have another machine running Debian 10 with pretty much the exact same setup but the MAC Adresses of the HW interface and br0 are identical. This post also points that out. Am I missing something here?
    – AlexD
    Commented Dec 11, 2021 at 11:57
  • Best guess I have is that someone thought "oh, let's just make that the default" and disimproved it without understanding the consequences. To be fair, in the context of VMs on a host you rarely will see network loops (unlike networking with cables and switches, where plugging a cable into the wrong port is easy, and that does extend to software bridges when they are part of that network).
    – dirkt
    Commented Dec 11, 2021 at 16:46
  • I described the current behavior on kernel 5.17 there (the behavior might or might not have slightly changed over time in kernel versions): superuser.com/questions/1720967/…
    – A.B
    Commented Jun 27, 2022 at 13:42
  • 1
    Your answer is wrong, at least in part. I just have upgraded two servers from Debian 10 to Debian 11 and couldn't reach both of them via network afterwards. The reason: Both machines had a bridge configured, and the O/S had assigned the same MAC address to both bridges. On both machines, outgoing packets had the bridge MAC address as HW address source, and both machines' network port was listening to to packets which had the bridges MAC address as destination, which naturally made the network unusable. This shows that br0 definitely is not purely internal.
    – Binarus
    Commented Oct 1, 2022 at 8:59
0

It is because of alphabetic order debian gets up interface files. It means that br0 is up before eno1 and has no mac to clone. Put interface eno1 definition into the same file with definition of br0 but ABOVE br0 definition - it is raises interfaces from top to bottom of file

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .