Bridging vs Routing in Linux Virtual Interfaces

Configuring network connectivity for virtual machines, containers, and network namespaces in Linux primarily relies on either bridging or routing. While both methods enable virtual interfaces (such as veth pairs or tap devices) to communicate with external networks and other hosts, they operate at different network abstraction layers, handle broadcast traffic differently, and demand distinct IP management strategies. Understanding these core differences ensures optimal performance, security, and scalability for virtualized Linux environments.

The Fundamental Difference: OSI Layers

The primary distinction between bridging and routing lies in the OSI layer at which each operates:

• Bridging operates at Layer 2 (Data Link Layer). A Linux bridge acts as a software-based network switch. It connects multiple physical or virtual network interfaces into a single Layer 2 segment, forwarding Ethernet frames based on Media Access Control (MAC) addresses.
• Routing operates at Layer 3 (Network Layer). Linux routing relies on the kernel's IP forwarding capabilities to move packets between separate subnets. It directs traffic based on destination IP addresses according to entries in the system's routing tables.

Linux Bridging: Characteristics and Behavior

In a bridged configuration, multiple virtual interfaces (such as tap interfaces for KVM/QEMU or veth endpoints for containers) are attached to a virtual bridge interface (often named br0 or docker0).

Key characteristics include:

• Unified Broadcast Domain: All interfaces attached to the bridge share the same broadcast and collision domain. Address Resolution Protocol (ARP) requests, DHCP broadcasts, and IPv6 neighbor discoveries traverse the bridge freely.
• Same Subnet Deployment: Guest instances connected to the bridge generally reside on the same IP subnet as the host's physical network adapter, allowing guests to appear as physical devices on the external network.
• MAC Learning: The bridge maintains a forwarding database (FDB) that maps MAC addresses to specific bridge ports, reducing unnecessary frame flooding over time.
• Configuration: Typically configured using ip link add name br0 type bridge and ip link set dev <interface> master br0.

Linux Routing: Characteristics and Behavior

In a routed configuration, the Linux host acts as a gateway or router. Each virtual interface or set of interfaces resides on a distinct IP subnet separate from the host's physical local area network.

Key characteristics include:

• Segmented Broadcast Domains: Layer 2 broadcast traffic is contained within the local virtual interface and does not cross into the physical network or other virtual networks, preventing broadcast storms.
• IP Forwarding: Packet transit between interfaces requires enabling IP forwarding in the kernel (net.ipv4.ip_forward=1).
• Network Address Translation (NAT) or Static Routes: Because guests sit on distinct subnets, external networks need static routes pointing back to the Linux host, or the host must perform Source NAT (masquerading) using iptables or nftables to rewrite outgoing traffic with its own physical IP address.
• Granular Traffic Control: Packet filtering, firewall rules, and policy-based routing can be strictly enforced at the IP layer before traffic moves between interfaces.

When to Choose Bridging vs. Routing

Use Bridging when:

• Virtual machines must directly acquire IP addresses from an existing physical LAN DHCP server.
• Legacy protocols that depend on Layer 2 broadcasts or non-IP protocols are required.
• Live migration of virtual machines across hosts requires preserving existing IP and MAC addresses seamlessly.

Use Routing when:

• Building large-scale container platforms (such as standard Kubernetes CNI plugins like Calico) where flat Layer 2 networks introduce MAC exhaustion and broadcast overhead.
• Strict network isolation and Layer 3 firewall policies are required between different virtual guests.
• Multiple isolated tenant networks need to run on a single host without overlapping broadcast domains.