if_bridge(4) contains the following paragraph: The if_bridge interface randomly chooses a link (MAC) address in the range reserved for locally administered addresses when it is created. This address is guaranteed to be unique only across all if_bridge interfaces on the local machine. Thus you can theoretically have two bridges on different machines with the same link addresses. The address can be changed by assigning the desired link address using ifconfig(8). It appears that the choice of bridge link address is not random, but is instead based on the value of kern.hostid. If two systems mistakenly end up with the same hostid, when using disk cloning for example, then the MAC address chosen for bridge interfaces will also be the same. To avoid confusion, this should be clarified. Also, the MAC address chosen for a bridge appears to always begin with the octets 58:9c:fc:10:xx:xx. The '8' as the second digit of the first octet indicates a universally administered address, not a locally administered one. https://en.wikipedia.org/wiki/MAC_address#Ranges_of_group_and_locally_administered_addresses
(In reply to Jason Mann from comment #0) > It appears that the choice of bridge link address is not random, but is instead > based on the value of kern.hostid IIRC, that is to have persistent MAC address (of cloned interfaces) across reboot.
https://standards-oui.ieee.org/oui/oui.txt says the following: 58-9C-FC (hex) FreeBSD Foundation 589CFC (base 16) FreeBSD Foundation P.O. Box 20247 Boulder CO 80308-3247 US -- Martin
(In reply to Martin Birgmeier from comment #2) Hi Martin, I am not sure I understand your comment. How is it relevant to the ticket? Thanks, Maxim
(In reply to Maxim Konovalov from comment #3) Please ignore, I got it. You are talking about the prefix part of the address.
So, I created the following diff that does two changes: 1. Clarifies the MAC address type, it is UAA instead of LAA. 2. Makes it clear that it is not random but rather a hash. The man page already covered possible MAC address conflict across different machines so I left this part intact. @@ -81,8 +81,11 @@ variable in .Pp The .Nm -interface randomly chooses a link (MAC) address in the range reserved for -locally administered addresses when it is created. +interface chooses a link (MAC) address in the range reserved for +universally administered addresses when it is created. +The address is derived from the host UUID, jail name, and the +.Nm +interface name. This address is guaranteed to be unique .Em only across all %%% Please let me know if the above good enough to be committed. Thanks, Maxim
To make it perfectly clear, you might want to replace "in the range reserved for universally administered addresses" by "in the range of universally administered addresses reserved for the FreeBSD Foundation" Since the Foundation got a full MA-L block (see also https://regauth.standards.ieee.org/standards-ra-web/pub/view.html), the -10 seems to be internally administrated within the Foundation. I am wondering whether they have some kind of registration authority where this is assigned, and whether that would be publicly viewable somewhere. Just to make sure, does the new wording reflect what is in the code? I mean, is it really coded as mentioned by Zhenlei Huang in comment 1? -- Martin
(In reply to Martin Birgmeier from comment #6) Hi Martin, Thanks, it makes sense to mention the authority explicitly. Yes, it should be persist across reboots but I am not sure if that was the idea behind. The code I am talking is in ether_gen_addr_byname(), https://cgit.freebsd.org/src/tree/sys/net/if_ethersubr.c#n1475 It is pretty much straightforward. Maxim
Looking at the code, maybe change this to When it is created, the .Nm interface gets assigned a link (MAC) address in the range of universally administered addresses reserved for the FreeBSD Foundation by hashing the host UUID, jail name, and the interface name. If this fails, a random, locally administered address is generated instead. -- Martin
(In reply to Martin Birgmeier from comment #8) This looks good, thanks. I'll commit it in next few days unless receive any objections. Maxim
Created attachment 260813 [details] bridge.4 proposed changes I attach the final diff that accumulates all previous input.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=08bc0097734824ff436769a95569e32575b51da3 commit 08bc0097734824ff436769a95569e32575b51da3 Author: Maxim Konovalov <maxim@FreeBSD.org> AuthorDate: 2025-06-03 19:19:59 +0000 Commit: Maxim Konovalov <maxim@FreeBSD.org> CommitDate: 2025-06-03 19:23:36 +0000 if_bridge.4: clarify how if_bridge assigns a MAC address PR: 283400 MFC after: 1 week share/man/man4/bridge.4 | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b53120be165637066b06203f246364a128041a2f commit b53120be165637066b06203f246364a128041a2f Author: Maxim Konovalov <maxim@FreeBSD.org> AuthorDate: 2025-06-03 19:19:59 +0000 Commit: Maxim Konovalov <maxim@FreeBSD.org> CommitDate: 2025-06-10 07:52:00 +0000 if_bridge.4: clarify how if_bridge assigns a MAC address PR: 283400 MFC after: 1 week (cherry picked from commit 08bc0097734824ff436769a95569e32575b51da3) share/man/man4/bridge.4 | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
All done.