Following an Ethernet frame from a virtual machine, across OVN logical networking, through Geneve tunnels, and onto the physical network.
Linux Bridge answers a narrow question well: how does a packet cross from a VM to a flat physical VLAN? But it has no answer for a much bigger one — what happens when two workloads that need to talk to each other live on different physical hosts, with no shared L2 segment stretched between them? Linux Bridge can't route across nodes on its own, and stretching VLANs across every rack in a datacenter doesn't scale past a few dozen nodes before spanning-tree and broadcast domains collapse under their own weight.
This is precisely the gap Kubernetes networking was built to close, and why every serious CNI is really a software-defined overlay in disguise. Instead of asking the physical network to understand pods, namespaces, and services, an overlay builds a completely independent logical network on top — one that doesn't care whether the underlying fabric has 3 nodes or 3,000, because every node only needs one thing from the physical network: plain IP reachability to every other node.
In this article, we'll follow the same kind of packet as before — but this time through OVN's logical overlay network, where the physical topology becomes almost irrelevant.
Before tracing the packet in detail, here's the complete journey at a glance — nine stages, no explanations yet.
| Component | Purpose |
|---|---|
| VM | Generates traffic via its guest networking stack |
| virt-launcher | The pod that hosts the running VM process |
| OVS (br-int) | Virtual switch — applies OpenFlow rules programmed by OVN |
| Logical Switch | Connects workloads on the same logical L2 segment |
| Distributed Router | L3 routing between subnets, runs locally on every node |
| Gateway Router | External connectivity — north-south traffic exit point |
| Geneve | Overlay tunnel protocol carrying traffic between nodes |
| Physical NIC | Sends the encapsulated packet onto the wire |
Same discipline as the Linux Bridge article — one packet, real IP addresses, every hop named. This time it travels from 10.128.2.15 to 10.128.3.22 on a different node.
Source 10.128.2.15, destination 10.128.3.22 — both cluster-internal IPs. No VLAN involved; the VM's default gateway is the OVN logical router.
The paravirtualized NIC hands the frame to QEMU, which writes it into the TAP device — the same handoff point as Linux Bridge networking.
Inside the virt-launcher pod, a small Linux bridge still does the first hop of L2 forwarding before the veth pair crosses into the host namespace.
The frame enters the host's Open vSwitch integration bridge, which attaches logical port ID, network segment, and ACL context via OpenFlow rules.
L2 segment processing determines the destination isn't local — it's on a remote node, so the frame routes to the logical router.
The distributed router evaluates 10.128.3.22, handles inter-subnet routing, applies SNAT/DNAT if needed, and determines the egress node.
The original frame is wrapped: outer IP (node → node), UDP port 6081, Geneve header carrying the VNI that identifies the logical network.
The now-encapsulated packet exits the host's physical interface toward the remote node's IP — plain UDP as far as the physical network is concerned.
The physical switch forwards the UDP packet using ordinary IP routing — it has zero awareness that a VM or Kubernetes is involved.
The destination node receives UDP:6081, strips the Geneve header, and recovers the original inner frame.
The remote node's br-int delivers the decapsulated frame through the same bridge/veth/tap chain in reverse, straight to the destination VM.
After eleven detailed steps, here's the same trip on one screen.
An overlay only does real work when the destination is actually on a different node. When two workloads land on the same node, OVN skips the entire Geneve pipeline.
This matters architecturally: the overlay isn't a permanent tax on every packet — it's a conditional cost that only applies when a packet genuinely needs to leave the node. Same-node traffic between two VMs, or a VM and a pod, is switched directly inside br-int at native kernel speed.
You don't need every implementation detail of the control plane to troubleshoot OVN — you need to know the direction data flows. Intent goes in one end, flows come out the other.
The Northbound DB stores desired state — the logical switches, routers, and ACLs that should exist. ovn-northd compiles that intent into logical flows written to the Southbound DB. Each node's ovn-controller reads only the flows relevant to it and programs local OVS — which is why OVN scales without a central packet-forwarding bottleneck.
This is the single biggest source of confusion when reading OVN diagrams. A "Logical Switch" is a database object, not a device. Here's the mapping every engineer eventually needs:
| Logical (OVN concept) | Physical (what actually runs) |
|---|---|
| Logical Switch | OVS Bridge (br-int) |
| Logical Router | OpenFlow rules + kernel routing |
| Logical Ports | OVS ports / veth interfaces |
| Logical Switch Port ACL | OpenFlow match + action rule |
This is the architectural idea that makes OVN fundamentally different from a traditional network: the logical router isn't a device anywhere — it's one logical object that runs locally, identically, on every node.
When Pod A on Node 1 talks to Pod B on Node 2, the routing decision is made entirely on Node 1 — there's no trip to a central router first. This is why the term is distributed: routing logic scales linearly with node count instead of bottlenecking through a single appliance.
The direct consequence: east-west traffic never leaves the cluster's logical network to make a routing decision, even though it does leave the node physically via Geneve. The physical hop and the logical routing decision are two separate concerns, and OVN keeps them that way deliberately.
This is the single biggest architectural distinction from the Linux Bridge article. Where Linux Bridge sends a native, unmodified Ethernet frame, OVN wraps the entire original frame inside a new one before it ever reaches the physical NIC.
The original VM-to-VM packet — with its own inner Ethernet and IP headers — is fully intact, just wrapped. The physical switch only ever reads the outer headers: a UDP packet between two node IPs. It never decodes, inspects, or even knows about the inner frame.
| Feature | OVN-Kubernetes |
|---|---|
| Overlay | Yes |
| Encapsulation | Geneve (UDP 6081) |
| Routing | Distributed — runs on every node |
| Multi-tenancy | Excellent — logical isolation per namespace/UDN |
| Network Policy | Native — enforced via OVN ACLs |
| Performance | High, with ~50 byte/packet overhead |
| Live Migration | Supported |
| Linux Bridge | OVN |
|---|---|
| Kernel Bridge | Open vSwitch |
| Native Ethernet | Geneve |
| Physical VLAN | Overlay |
| Simple L2 | SDN |
This is a concept comparison only — the full seven-way matrix lives in the Cloud-Native Networking Architecture Portal.