LFCE 19 🐧 Network Bridges — Concepts - KandZ

⏱️ Estimated read: 12 min | |

A Linux bridge is a software switch. It connects two or more network interfaces at Layer 2, forwarding Ethernet frames between them based on MAC addresses, not IP addresses. The bridge itself becomes a logical interface—typically br0—that carries an IP address, while the physical interfaces attached to it become ports, stripped of their own addresses . This distinction is fundamental: the bridge is the host’s presence on the network, and the ports are the wires that connect it to other devices.

For the LFCE candidate, bridges appear in three recurring contexts. Virtualization platforms attach virtual machine NICs to a bridge so the VMs appear on the same LAN as the host. Container networking uses bridges to connect container namespaces to the host’s physical network. And network testing labs use bridges to simulate switch topologies without dedicated hardware. Understanding what the bridge does—and what it does not do—is the foundation for configuring these scenarios correctly.

Key point: A bridge forwards frames based on a MAC address table it learns dynamically. It does not route IP packets, it does not separate broadcast domains, and it does not appear in traceroute because it is transparent to the network . A bridge with an IP address is a host on the bridged network; a bridge without an IP address is a pure switch.

Why Linux bridges exist

The soft-switch problem.

A physical switch is a dedicated appliance that forwards frames between its ports. It works well, but it cannot be configured with the flexibility of a Linux host. A bridge provides the same Layer 2 forwarding behavior in software, attached to the Linux networking stack. This means the bridge can be combined with iptables, nftables, and tc for filtering and traffic shaping—capabilities that dedicated switches rarely offer at the same level of granularity . The bridge is not a replacement for a data center switch; it is an extension of the host’s networking capabilities.

The virtualization problem.

A virtual machine needs a network interface. That interface is virtual—a TAP device or a veth pair—and it must connect to the physical network. The bridge is the junction. The VM’s virtual NIC is attached to the bridge as a port, and the host’s physical NIC is attached as another port. Frames from the VM enter the bridge through the virtual port and exit through the physical port, reaching the physical switch as if the VM were a physical host on the wire . Without the bridge, the VM would be isolated or require routing, which breaks the assumption that VMs and physical hosts share a subnet.

The hub confusion problem.

A hub is a Layer 1 repeater. It receives a frame on one port and transmits it on every other port, regardless of destination. A bridge is a Layer 2 switch. It learns which MAC addresses are reachable through which ports and forwards frames only to the port that leads to the destination . This distinction matters because a bridge does not create the collision and bandwidth-waste problems that a hub does. When a bridge receives a frame for an unknown destination, it floods the frame to all ports except the one it arrived on. Once the destination replies, the bridge learns the MAC-to-port mapping and stops flooding for that address .

a. How a bridge forwards frames

A bridge maintains a forwarding database (FDB) that maps MAC addresses to ports. When a frame arrives, the bridge looks up the destination MAC address in the FDB.

# Show the MAC address table learned by the bridge
brctl showmacs br0

# Output includes columns for port number, MAC address, is-local flag, and ageing timer
# The is-local flag indicates the bridge's own MAC address

If the destination MAC is in the FDB, the bridge forwards the frame only to the port associated with that address. If the destination is not in the FDB, the bridge floods the frame to every port except the ingress port. When the destination responds, the bridge learns its port from the source MAC of the reply .

# The bridge ages out learned entries to handle topology changes
# Default ageing time is 300 seconds
brctl setageing br0 300

# A shorter ageing time adapts faster to changes but increases flooding

The ageing timer prevents stale entries from persisting after a device moves to a different port. When an entry expires, the bridge treats the address as unknown and floods until it is learned again .

b. Spanning Tree Protocol and loop prevention

A bridge without loop prevention is dangerous. If two bridges are connected by more than one path, a broadcast frame can circulate indefinitely, consuming all available bandwidth. The Spanning Tree Protocol (STP) prevents this by electing a root bridge and placing redundant ports in a blocking state .

# Enable STP on a bridge (it may be on by default depending on the tool)
brctl stp br0 on

# Show the bridge's STP state
brctl showstp br0

# Output includes the bridge ID, root bridge ID, and port roles

The root bridge is the bridge with the lowest bridge ID. All other bridges calculate the shortest path to the root and block ports that would create a loop. When the topology changes—a cable is unplugged, a bridge fails—STP recalculates and unblocks a previously blocked port to restore connectivity .

STP has no authentication. Any device that sends BPDUs (Bridge Protocol Data Units) can participate in the topology calculation. For this reason, STP should not be enabled on a bridge that connects to an untrusted network without filtering BPDUs at the boundary .

c. Bridges in virtualization and container networking

The most common use of Linux bridges today is connecting virtual interfaces to physical networks. A virtual machine’s TAP device or a container’s veth pair is attached to the bridge as a port. The bridge forwards frames between the virtual port and the physical port, making the virtual machine appear as a physical host on the LAN .

# Create a bridge for virtual machines
ip link add name br0 type bridge

# Attach the physical interface to the bridge
ip link set eth0 master br0

# The physical interface should not have an IP address
# The bridge carries the host's IP address
ip addr add 192.168.1.100/24 dev br0
ip link set br0 up
ip link set eth0 up

When the physical interface is attached to the bridge, any IP address configured directly on it becomes unreachable because the interface is now a port, not a routed endpoint. The address must be moved to the bridge interface . This is the most common configuration mistake: adding eth0 to br0 while leaving eth0‘s IP address in place, which produces a host that appears to have an address but cannot communicate.

For containers, the same pattern applies. The container runtime creates a veth pair, places one end in the container’s namespace, and attaches the other end to the bridge. The container’s traffic traverses the bridge and exits through the physical interface, sharing the host’s Layer 2 segment.

Complete Example Session

# ============================================
# PART 1: CREATE THE BRIDGE
# ============================================
# Create a bridge interface named br0
ip link add name br0 type bridge

# ============================================
# PART 2: ATTACH PHYSICAL INTERFACES
# ============================================
# Attach eth0 and eth1 to the bridge as ports
ip link set eth0 master br0
ip link set eth1 master br0

# ============================================
# PART 3: REMOVE IP ADDRESSES FROM PORTS
# ============================================
# The physical interfaces must not have IP addresses
# The bridge carries the host's address
ip addr flush dev eth0
ip addr flush dev eth1

# ============================================
# PART 4: ASSIGN AN IP TO THE BRIDGE
# ============================================
# The bridge is the host's presence on the network
ip addr add 192.168.1.100/24 dev br0

# ============================================
# PART 5: BRING UP THE BRIDGE AND PORTS
# ============================================
ip link set br0 up
ip link set eth0 up
ip link set eth1 up

# ============================================
# PART 6: VERIFY THE BRIDGE CONFIGURATION
# ============================================
ip link show master br0
# Output: eth0 and eth1 are listed as bridge ports

ip addr show br0
# Output: inet 192.168.1.100/24

# ============================================
# PART 7: INSPECT THE FORWARDING DATABASE
# ============================================
brctl showmacs br0
# Output shows learned MAC addresses after traffic flows

# ============================================
# PART 8: CHECK STP STATE
# ============================================
brctl showstp br0
# Output shows bridge ID, root ID, and port states

# ============================================
# PART 9: ATTACH A VIRTUAL MACHINE INTERFACE
# ============================================
# A TAP device is created by the hypervisor
# It is attached to the bridge as a port
ip link set tap0 master br0
ip link set tap0 up

# ============================================
# PART 10: VERIFY CONNECTIVITY
# ============================================
# The host should be reachable at the bridge address
ping -c 2 192.168.1.1
# The VM attached to tap0 should be reachable on the same subnet

The ten parts demonstrate the complete bridge configuration: create, attach, strip addresses, assign to bridge, verify, and extend with virtual interfaces. The critical step is Part 3—removing IP addresses from the physical ports—because a port with an address violates the bridge model and produces unpredictable behavior.

Quick Reference

Bridge Commands

Task	Command
Create bridge	`ip link add name br0 type bridge`
Attach port	`ip link set eth0 master br0`
Detach port	`ip link set eth0 nomaster`
Remove IP from port	`ip addr flush dev eth0`
Assign IP to bridge	`ip addr add <addr>/<prefix> dev br0`
Bring up	`ip link set br0 up`
Show ports	`ip link show master br0`
Show MAC table	`brctl showmacs br0`
Show STP state	`brctl showstp br0`

Bridge vs Other Devices

Device	Layer	Forwarding Decision
Hub	L1	Floods to all ports
Bridge	L2	MAC address table
Switch	L2	MAC address table (multi-port bridge)
Router	L3	IP routing table

Key Concepts

Concept	Meaning
FDB	Forwarding database; MAC-to-port mapping
Ageing time	Seconds before a learned MAC entry expires
STP	Spanning Tree Protocol; prevents loops
Root bridge	Bridge with lowest bridge ID
BPDU	Bridge Protocol Data Unit; STP message

Best Practices

✅ Do This:

# Remove IP addresses from ports before attaching
ip addr flush dev eth0                                      # ✅

# Assign the host's IP to the bridge, not the port
ip addr add 192.168.1.100/24 dev br0                        # ✅

# Verify STP is enabled if loops are possible
brctl stp br0 on                                            # ✅

# Check the FDB after traffic flows
brctl showmacs br0                                          # ✅

# Use the bridge interface for all host-level configuration
ip route add default via 192.168.1.1 dev br0                # ✅

# Disable STP on bridges connected to untrusted networks
# or filter BPDUs at the boundary                             # ✅

❌ Don’t Do This:

# Leave an IP address on a bridge port
# The port is no longer a routed interface                    # ❌

# Attach a port without flushing its address first
ip link set eth0 master br0  # eth0 still has an IP        # ❌

# Enable STP on a bridge facing the internet
# STP has no authentication                                  # ❌

# Expect a bridge to separate broadcast domains
# Bridges extend broadcast domains; routers separate them    # ❌

# Use a bridge when routing is required
# Bridges forward frames; routers forward packets           # ❌

# Forget to bring up the bridge and ports
ip link set br0 up; ip link set eth0 up                     # ❌ (often missed)

Common Pitfalls

Pitfall	Why It Happens	Fix
Host unreachable after adding port to bridge	Port still has IP address	`ip addr flush dev eth0`
No connectivity through bridge	Bridge or port is down	`ip link set br0 up`; `ip link set eth0 up`
Broadcast storm	Loop in topology with STP disabled	Enable STP or remove redundant path
VM cannot reach network	TAP device not attached to bridge	`ip link set tap0 master br0`
Bridge not visible in traceroute	Bridge is transparent by design	Expected behavior
MAC table empty	No traffic has flowed yet	Generate traffic to populate FDB

Real-World Examples

1. Create a bridge

ip link add name br0 type bridge

2. Attach a physical port

ip link set eth0 master br0

3. Flush port addresses

ip addr flush dev eth0

4. Assign bridge IP

ip addr add 192.168.1.100/24 dev br0

5. Attach a TAP device for a VM

ip link set tap0 master br0

6. Show MAC table

brctl showmacs br0

7. Enable STP

brctl stp br0 on

8. Show STP state

brctl showstp br0

9. Detach a port

ip link set eth0 nomaster

10. Verify bridge ports

ip link show master br0

Visual

Bridge as a Soft Switch

┌──────────────────────────────────────────────────────────────┐
│  LINUX BRIDGE FORWARDS FRAMES AT LAYER 2                     │
│                                                              │
│  ┌─────────┐                                                 │
│  │  eth0   │───┐                                             │
│  └─────────┘   │                                             │
│                │     ┌─────────────────────────┐             │
│  ┌─────────┐   ├────▶│        br0             │             │
│  │  eth1   │───┤     │   (software switch)     │             │
│  └─────────┘   │     │                         │             │
│                │     │  FDB: MAC → port        │             │
│  ┌─────────┐   │     └────────────┬────────────┘             │
│  │  tap0   │───┘                  │                          │
│  └─────────┘                      │                          │
│  (VM NIC)                         ▼                          │
│                          ┌─────────────────┐                 │
│                          │  Host IP        │                 │
│                          │  192.168.1.100  │                 │
│                          └─────────────────┘                 │
│                                                              │
│  Ports have no IP addresses.                                 │
│  The bridge carries the host's address.                      │
│  Frames are forwarded by MAC, not IP.                        │
└──────────────────────────────────────────────────────────────┘

Bridge vs Hub

┌──────────────────────────────────────────────────────────────┐
│  HUB FLOODS; BRIDGE LEARNS                                   │
│                                                              │
│  HUB (Layer 1):                                              │
│  Frame from A destined to B                                  │
│  ┌───┐                                                       │
│  │ A │───┐                                                   │
│  └───┘   │     ┌─────────┐                                   │
│          ├────▶│   HUB   │────▶ A (discard)                  │
│  ┌───┐   │     │ (flood) │────▶ B (deliver)                  │
│  │ B │───┤     └─────────┘────▶ C (waste)                    │
│  └───┘   │                                                  │
│  ┌───┐   │                                                  │
│  │ C │───┘                                                   │
│  └───┘                                                       │
│                                                              │
│  BRIDGE (Layer 2):                                           │
│  Frame from A destined to B                                  │
│  ┌───┐                                                       │
│  │ A │───┐                                                   │
│  └───┘   │     ┌─────────┐                                   │
│          ├────▶│ BRIDGE  │────▶ A (discard)                  │
│  ┌───┐   │     │ (FDB)   │────▶ B (deliver only)             │
│  │ B │───┤     └─────────┘────▶ C (not sent)                 │
│  └───┘   │                                                  │
│  ┌───┐   │                                                  │
│  │ C │───┘                                                   │
│  └───┘                                                       │
│                                                              │
│  Bridge learns B is on the port toward B and sends only there│
└──────────────────────────────────────────────────────────────┘

Bridge in Virtualization

┌──────────────────────────────────────────────────────────────┐
│  VM AND HOST SHARE THE SAME LAYER 2 SEGMENT                  │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Physical Network                                       │  │
│  │ 192.168.1.0/24                                         │  │
│  └──────────────────────────┬─────────────────────────────┘  │
│                             │                                │
│                             │ eth0                           │
│                             ▼                                │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Linux Host                                             │  │
│  │                                                        │  │
│  │  ┌──────────────────────────────────────────────────┐  │  │
│  │  │ br0 (192.168.1.100)                              │  │  │
│  │  │                                                  │  │  │
│  │  │  ┌────────┐  ┌────────┐  ┌────────┐              │  │  │
│  │  │  │ eth0   │  │ tap0   │  │ tap1   │              │  │  │
│  │  │  └────────┘  └───┬────┘  └───┬────┘              │  │  │
│  │  └──────────────────┼───────────┼───────────────────┘  │  │
│  │                     │           │                      │  │
│  │              ┌──────▼─────┐ ┌───▼────────┐             │  │
│  │              │   VM 1     │ │   VM 2     │             │  │
│  │              │ 192.168.1.101│ 192.168.1.102│            │  │
│  │              └────────────┘ └────────────┘             │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  VMs appear as physical hosts on the LAN.                    │
│  The bridge forwards frames between tap devices and eth0.    │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Bridge function	Layer 2 frame forwarding between ports
Logical interface	`br0`, `br1`, etc.
Port interfaces	Physical NICs or virtual interfaces
Forwarding decision	MAC address table (FDB)
Flooding	Unknown destinations sent to all ports except ingress
IP address	On the bridge, not on the ports
STP	Prevents loops; disabled by default on some distributions
Traceroute visibility	Transparent; does not appear
Broadcast domain	Extends, does not separate
Common use case	Virtualization, container networking

Key takeaways:

The bridge is the host’s interface; the ports are the wires. An IP address belongs on br0, not on eth0 or eth1. Attaching a port to a bridge without flushing its address produces a host that appears configured but cannot communicate .
Bridges forward by MAC, not IP. The forwarding database learns which MAC addresses are reachable through which ports. Unknown destinations are flooded until the address is learned .
A bridge is a switch, not a hub. It does not replicate every frame to every port. It forwards intelligently after learning the topology .
STP prevents loops but has no authentication. Enable it when loops are possible, disable it on untrusted boundaries, and understand that it recalculates the topology when links change .
Bridges extend broadcast domains; routers separate them. A bridge does not stop broadcasts. If broadcast separation is required, a router or VLAN configuration is necessary.
The bridge is transparent to the network. It does not appear in traceroute because it does not decrement TTL or modify frames. It is invisible infrastructure .

Remember: A Linux bridge is a software switch that connects interfaces at Layer 2. It learns MAC addresses, forwards frames intelligently, and presents a single logical interface to the host. The bridge carries the IP address; the ports carry the frames. Configure the bridge first, flush the ports, attach the ports, then assign the address. Verify with ip link show master br0 and brctl showmacs br0. A bridge that floods every frame is a hub. A bridge that forwards only where needed is a switch. The difference is the FDB, and the FDB learns from traffic.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!