Understanding how packets traverse Linux Bridge networking in OpenShift Virtualization — from the virtual machine to the physical switch.
Almost every architecture diagram of a virtualized workload ends the same way: a box labeled "VM," a line to a box labeled "Network," and nothing in between. That gap is where most production networking incidents live. The packet doesn't teleport from the guest OS to the physical switch — it crosses a TAP device, a kernel bridge, a namespace boundary, another kernel bridge, and finally a physical NIC, and every one of those hops is a place where MTU mismatches, VLAN misconfigurations, and namespace confusion actually happen.
Architects frequently misunderstand Linux Bridge specifically because it looks deceptively simple compared to OVN. There's no SDN controller, no logical switch object, no northbound database to inspect — which leads many to assume there's "nothing to understand." In practice, the opposite is true: because there's no controller abstracting the mechanics away, you have to understand the raw kernel primitives directly to troubleshoot it at all.
Understanding the exact packet path isn't academic. It's the difference between guessing at a connectivity issue and knowing precisely which hop to inspect first.
In this article, we'll follow a single packet from inside a virtual machine all the way to the physical network.
Before we trace the packet in detail, here's the full path at a glance. No explanations yet — just orientation.
| Component | Purpose |
|---|---|
| VM | Generates packets via its guest OS networking stack |
| virt-launcher | The pod that hosts the running VM process (QEMU) |
| tap0 | Connects QEMU's virtual NIC to the Linux Bridge |
| Linux Bridge (br1) | Layer-2 switching inside the pod network namespace |
| veth pair | Crosses the pod ↔ host namespace boundary |
| Host Bridge (br0) | Connects the pod's veth to the physical NIC |
| Physical NIC | Sends the native Ethernet frame to the wire |
This is the walkthrough every BitByteIntegration article is built around. Ten steps, one packet, no abstraction skipped.
A process inside the guest OS opens a socket and writes data — an ordinary application-layer send.
The guest kernel wraps the payload through TCP/IP and hands it to the network device driver.
The paravirtualized NIC driver passes the frame to QEMU with minimal virtualization overhead.
QEMU writes the frame into the TAP device — the virtual cable connecting the VM process to the host's network stack.
Inside the virt-launcher pod's namespace, the local bridge performs L2 switching and forwards toward eth1.
The frame reaches eth1 in the pod and instantly appears on the paired veth interface in the host namespace.
The frame is now visible to the node's own network stack, outside any pod isolation.
The host bridge performs a standard L2 lookup and forwards the frame — just like a physical switch would.
The frame is pushed onto the physical interface (e.g. ens5f0), attached to br0 as an access or trunk port.
The top-of-rack switch receives a plain Ethernet frame and forwards it exactly as it would for a bare-metal server.
bridge fdb show or ip link directly on the node and see this exact topology — nothing here is abstracted behind a controller.This deserves its own section because the namespace boundary is where most engineers new to containers lose the thread. A network namespace is a completely isolated instance of the Linux network stack — its own interfaces, routes, and firewall rules. The pod's namespace and the host's namespace are two separate worlds, and a veth pair is the only bridge between them.
A veth pair is always created as two ends of the same virtual cable: one end is placed inside the pod's namespace (eth1), the other stays in the host namespace (vethXXXX). Whatever enters one end instantly appears on the other — there's no queueing, no processing delay, no protocol translation. It's the closest thing Linux has to a network-layer teleporter, which is exactly why it's the standard mechanism every container network plugin uses to cross namespace boundaries.
Everything in this article so far has depended on one fact: the Linux kernel bridge is the network. There's no SDN controller reasoning about topology, no software-defined overlay, no encapsulation protocol — just a kernel subsystem doing exactly what a physical Layer-2 switch does.
Every bridge maintains a Forwarding Database (FDB) — a table mapping MAC addresses to the port they were last seen on. The first time a frame arrives from a new source MAC, the bridge records which port it came in on. From then on, frames destined for that MAC are forwarded directly to that port instead of being flooded to every port on the bridge.
The bridge never inspects anything above Layer 2. It doesn't care about IP addresses, TCP ports, or application data — it reads a destination MAC, checks the FDB, and forwards. This is precisely why Linux Bridge networking has effectively zero CPU overhead compared to any SDN-based alternative.
This is the biggest conceptual difference between Linux Bridge and any overlay-based network type like OVN. There is no Geneve header, no VXLAN header, no GRE tunnel wrapping the packet. What leaves the physical NIC is a native, unmodified Ethernet frame — identical in structure to what any bare-metal server would send.
No decapsulation logic runs anywhere along this path. There's nothing to strip, nothing to unwrap — the destination MAC is looked up in a switch's own FDB exactly like any other frame on the network.
| Feature | Linux Bridge |
|---|---|
| Overlay | No |
| Encapsulation | No |
| VLAN Support | Yes — via vlan_filtering=1 |
| Live Migration | Yes — full L2 semantics preserved |
| Performance | High — near-native, kernel-only path |
| SDN / Controller | No |
| Linux Bridge | OVN | SR-IOV | |
|---|---|---|---|
| Switching | Kernel | OVS | Hardware (VF) |
| Encapsulation | No | Geneve | No |
| Latency | Low | Medium | Lowest |
| Live Migration | Yes | Yes | Complex |
This is a snapshot only — the full comparison matrix across all seven network types lives in the Cloud-Native Networking Architecture Portal.