Why assign MAC and IP addresses on Bridge interface

Say I create a bridge interface on linux (br0) and add to it some interfaces (eth0, tap0, etc.). My understanding is that this interface act like a virtual switch with all its interfaces/ports that I add to it.

What is the meaning of assigning a MAC and an IP address to that interface? Does the interface act as an additional port on the switch/bridge which allows other ports to access the host machine?

I have seen some pages talk about assigning an IP address to a bridge. Is the MAC assignation implied (or automatic)?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Because a bridge is an ethernet device it needs a MAC address. A linux bridge can originate things like spanning-tree protocol frames, and traffic like that needs an origin MAC address.

A bridge does not require an ip address. There are many situations in which you won’t have one. However, in many cases you may have one, such as:

  • When the bridge is acting as the default gateway for a group of containers or virtual machines (or even physical interfaces). In this case it needs an ip address (because routing happens at the IP layer).
  • When your “primary” NIC is a member of the bridge, such that the bridge is your connectivity to the outside world. In this case, rather than assigning an ip address to (for example) eth0, you would assign it to the bridge device instead.

If the bridge is not required for ip routing, then it doesn’t need an ip address. Examples of this situation include:

  • When the bridge is being used to create a private network of devices with no external connectivity, or with external connectivity provided through a device other than the bridge.

Method 2

Yes, the bridge interface acts as an additional port.

After man 5 systemd.netdev:

A bridge device is a software switch, and each of its slave devices and the bridge itself are ports of the switch.

Method 3

The bridge device listed with your other networking devices does not represent the virtual bridge, it represents a virtual NIC that is connected to the bridge. If you had a physical bridge connected with physical networking devices, you wouldn’t see the physical bridge listed in your networking devices either — but you would see your NIC that is connected to the bridge, which of course has its own MAC address like any other network device.

Assigning an IP adress to the bridge device (which, again, is actually a virtual NIC connected to the virtual bridge) allows your host device to route packets to the subnet created by the bridge and all of the devices attached to it. Neat!

While networking device tools such as iproute2 (with the ip link and ip addr commands) allow you to see the virtual NIC attached to the bridge, it is also possible to see the virtual bridge itself with the brctl program. The brctl show command will list all bridges and their attached interfaces. Here is an example using iproute and brctl with Linux bridges and tuntaps:

# ip link add br0 type bridge
# ip tuntap add dev tap0 mode tap
# ip tuntap add dev tap1 mode tap
# ip addr add 10.0.0.1/24 broadcast 10.0.0.255 dev br0
# ip addr add 10.0.0.2/24 broadcast 10.0.0.255 dev tap0
# ip addr add 10.0.0.3/24 broadcast 10.0.0.255 dev tap1
# brctl addif br0 tap0
# brctl addif br0 tap1
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.2e22e593fe8c       no              tap0
                                                        tap1
# ip addr show to 10.0.0.0/24
11: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global br0
       valid_lft forever preferred_lft forever
12: tap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    inet 10.0.0.2/24 brd 10.0.0.255 scope global tap0
       valid_lft forever preferred_lft forever
13: tap1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    inet 10.0.0.3/24 brd 10.0.0.255 scope global tap1
       valid_lft forever preferred_lft forever

Note that what is listed under “interfaces” in the output of brctl show are the other interafces attached to the bridge, in addition to the br0 interface that was automatically added when the bridge was created. (I guess Linux doesn’t allow creating a virtual bridge with no attached devices, and bridges with no devices are automatically destroyed.) For the record, I haven’t researched this in the kernel, nor am I a networking expert. I posted this because it seems to convincingly explain the rather confusing implementation of virtual bridges in Linux. I do not believe that the virtual bridges themselves even have MAC addresses.

Method 4

The br0 and virbr0 interfaces listed by ip addr and ip link are tap interfaces that connect the host to the br0 bridge and virbr0 bridge respectively. This overloading of names can certainly be confusing.

So what is virbr0-nic?

This was not part of the original question but I’ll add my 2 cents here since this confused me in the past. virbr0-nic is a dummy interface whose MAC address is used by the virbr0 bridge as its own mac address. This always-present interface is there to prevent virbr0‘s MAC address from changing when ports are dynamically added or removed from the bridge. The host does not send any traffic out the virbr0-nic interface.

See https://backreference.org/2010/07/28/linux-bridge-mac-addresses-and-dynamic-ports and https://www.redhat.com/archives/libvirt-users/2012-September/msg00038.html for an explanation.


All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

0 0 votes
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments