How Linux Bridges Work: Step‑by‑Step Guide with iproute2, veth, and Real‑World Scenarios

What is a Linux bridge?

A Linux bridge is a virtual network device that functions like an Ethernet switch. It can have its own MAC and optional IP address, learns MAC addresses, and forwards frames between its ports based on that learning.

Creating a bridge

sudo ip link add name br0 type bridge
sudo ip link set br0 up

When first created, the bridge has only one port – the protocol stack – and no connectivity to other interfaces.

Connecting veth pairs to the bridge

# create a veth pair
sudo ip link add veth0 type veth peer name veth1
# assign IPs for testing
sudo ip addr add 192.168.3.101/24 dev veth0
sudo ip addr add 192.168.3.102/24 dev veth1
# bring the interfaces up
sudo ip link set veth0 up
sudo ip link set veth1 up
# attach one end to the bridge
sudo ip link set dev veth0 master br0
# verify the link
sudo bridge link

After the attachment, br0 and veth0 form a bidirectional channel. The bridge adopts the MAC address of veth0, and the protocol stack sees veth0 as a simple wire. The stack can send packets to veth0, but replies arriving on veth0 are intercepted by the bridge and are not delivered to the stack.

Observations

Bidirectional traffic between br0 and veth0.

The protocol stack can transmit to veth0, but incoming frames on veth0 are consumed by the bridge, not the stack. br0 inherits the MAC address of veth0.

Because the stack never learns the MAC of veth1, a ping from veth0 to veth1 fails – the ARP reply is delivered to the bridge instead of the stack.

Assigning an IP address to the bridge

# remove the IP from the veth end
sudo ip addr del 192.168.3.101/24 dev veth0
# assign it to the bridge instead
sudo ip addr add 192.168.3.101/24 dev br0

Now br0 holds the address 192.168.3.101 and can ping veth1. However, the bridge still cannot reach the external gateway because it has no route to that network.

Adding a physical NIC to the bridge

# attach the host NIC to the bridge
sudo ip link set dev eth0 master br0
# show bridge ports
sudo bridge link

After adding eth0, the bridge treats the physical interface like any other port. The original IP on eth0 must be removed to avoid routing conflicts: sudo ip addr del 192.168.3.21/24 dev eth0 Removing the host IP also removes the default route; it must be re‑added manually if external connectivity is required:

sudo ip route add default via 192.168.3.1

Important considerations

When running inside a virtual machine, enable promiscuous mode on the VM’s network adapter; otherwise packets destined for veth1 may be dropped.

Linux may reply to a single ARP request with two replies (one for br0 and one for veth1). This can cause intermittent communication because the remote host may choose either MAC. Tuning rp_filter, arp_filter, arp_ignore, and arp_announce can mitigate the issue but is complex.

In wireless environments the upstream access point usually binds a single MAC address to the client. Aligning the MAC addresses of all bridge‑connected interfaces to the physical NIC’s MAC avoids MAC‑translation problems.

Does a bridge need an IP address?

Like a hardware switch, a bridge can operate without an IP address. An IP is only required for management or when the bridge itself must act as a host (e.g., for routing or NAT). Removing the IP from br0 does not affect traffic forwarding between its member ports.

Typical use cases

Virtual machines

VMs attach their virtual NICs (via tap, vhost‑net, etc.) to a Linux bridge. Frames from the VM are forwarded by the bridge directly to the physical NIC and out to the external network, bypassing the host’s network stack. This provides near‑native performance.

Docker containers

Each container runs in its own network namespace with a veth pair. One end of the pair is placed in the container, the other end is attached to a bridge on the host. Outbound packets are forwarded to the host, which performs IP forwarding and optional NAT before sending them out through the physical NIC. Although this adds a processing step compared with VMs, it isolates containers on an internal network and avoids the multiple‑ARP problem described earlier.