How does Linux determine the default MAC address of a bridge device? I know it is the same as "bridge id" from brctl show, but how is it calculated? Is the MAC address supposed to change automatically when a network interface is added to the bridge?


1 Answer 1


Behavior might possibly have changed in the past depending on kernel version, but currently (here: kernel 5.17.x) it appears that:

  • if the bridge has not be manually given a MAC address then

    • it initially gets an autogenerated random MAC address with private bit set (ie: 2nd digit in MAC address' first byte is always 2,6,a or e).
    • until the first time an interface is set as bridge port, when administratively UP it gets a LOWER_UP flag and its operstate is UNKNOWN, which gives it the benefit of the doubt as if UP (eg with systl -w net.ipv4.conf.br0.ignore_routes_with_linkdown=1, route is working and doesn't have the linkdown property).
    • once at least one interface has ever been enslaved as bridge port:
      • each time a bridge port is added or removed the bridge interface dynamically inherits the lowest MAC address among all its bridge ports' MAC addresses.
      • should it then lose all of its interfaces, its MAC address becomes 00:00:00:00:00:00, until a port is added back
      • its operstate is UP if it's administratively UP and at least one of its bridge ports has operstate UP (usually: administratively UP and has carrier, ie: doesn't have the NO-CARRIER property)
      • if administratively UP but all of its ports have operstate DOWN (usually: administratively DOWN or have the NO-CARRIER property) then the bridge interface gets the NO-CARRIER property and its operstate is DOWN (and for example with ignore_routes_with_linkdown=1, routes will have the dead/linkdown properties).
  • if the bridge's MAC address is set manually (with a different value than from its current auto-generated or inherited address if not set at creation)

    • the bridge's MAC address will not change when bridge ports are added or removed

    • operstate isn't UNKNOWN when administratively set UP when there has never been any bridge port added yet: it's DOWN.

    • and follows the previously described behavior with regard to its operstate and its port's operstates : UP when there's at least a bridge port with operstate UP, DOWN otherwise.

I couldn't find any documentation explaining the reason for these different behaviors related to having or not having set a MAC address on the bridge on Linux. There might possibly be an historical relation to how the bridge id is evaluated.

To avoid any surprise, just set the MAC address.

Example for a bridge named br0:

ip link set dev br0 address 12:34:56:78:9a:bc

or at creation:

ip link add name br0 address 12:34:56:78:9a:bc up type bridge

One can still set it with the MAC address of some pre-existing (physical) interface intended to be enslaved, for example to avoid changing DHCP behavior when requesting an IP address on br0 without using DUID. It should probably be set before enslaving the interface because setting it after might actually have no effect as written above (setting the bridge interface's MAC address to its same current value has no effect and doesn't switch to the second behavior).

For example to copy eth0's MAC address when creating br0 to keep DHCP behavior consistent (with eth0 intended to be enslaved to br0 and on the side of the DHCP server), with the help of JSON output and the jq command:

ip link add name br0 address "$(ip -json link show dev eth0 | jq -r .[].address)" up type bridge

and only then enslave the interface:

ip link set dev eth0 up master br0

One can only hope existing network configuration tools can do this correctly.

Note: just as ifconfig or route on Linux, brctl is an obsolete command. It still uses the older kernel API. This has been superseded by ip link plus bridge which use the newer (rt)netlink API providing new features (eg: hairpin), but arguably may have a less human-readable output.

Example of commands:

ip -details link show type bridge
bridge -details link show
  • 3
    If you gave your layout (ip link show type bridge; ip link show type bridge_slave, if there's only one bridge then -brief option can be added) I guess it could be explained.
    – A.B
    Jun 11, 2022 at 8:56
  • 1
    And by the way, technically I did answer your question: I explained how the default MAC address is determined. Your specific problem has not been stated, so I couldn't answer it.
    – A.B
    Jun 11, 2022 at 9:25
  • 1
    @jurez meanwhile I know why: you are never in the first case. The value (random but always the same) is set by systemd. See my answer in this UL SE Q/A: unix.stackexchange.com/questions/719379/…
    – A.B
    Jun 13, 2023 at 8:35
  • 1
    The correct solution is in my answer (the 3 commands to change the machine-id) It's not Debian specific but systemd specific. If your init is systemd (and not say init sys v) then it applies, whatever are your network tools. If you want I update my answer, you must first update your question explaining what was your actual problem (which doesn't appear in your question).
    – A.B
    Jun 13, 2023 at 14:20
  • 1
    Really no. it's done by one of the components of systemd whenever it detects a virtual interface appeared (that's easy, try it with ip monitor) even if an entirely different tool (eg: ifupdown's ifup) created it. You'd have to search systemd's sources. By the way now, if your problem is solved, please consider marking my answer ans solution, heh.
    – A.B
    Jun 13, 2023 at 16:33

You must log in to answer this question.

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