Following a packet from a virtual machine through OVN Localnet and onto an existing enterprise VLAN — without Geneve encapsulation.
Almost no enterprise adopts OpenShift Virtualization on a blank slate. The VLANs already exist. The firewalls already exist, with rules written against known subnets. The DHCP scopes already exist. The physical switches already exist, purchased and depreciated over a multi-year budget cycle nobody wants to reopen.
Part 2 showed how OVN solves cross-node networking beautifully — by hiding the physical topology entirely behind a Geneve overlay. But that's exactly the problem for a workload that needs to appear directly on VLAN 200, reachable by its real IP from an existing firewall rule, indistinguishable from the bare-metal server sitting in the next rack. An overlay IP living inside Geneve simply isn't visible to that infrastructure.
How can OVN connect a workload directly to that physical network, while still keeping the workload under OVN's control plane? That's Localnet — and it's the subject of this article.
Nine stages, no explanations yet — just the shape of the journey.
| Component | Purpose |
|---|---|
| VM | Generates packets via its guest networking stack |
| OVS | Virtual switching — same br-int used by default OVN networking |
| Logical Switch | The logical L2 segment the VM's port belongs to |
| Localnet Port | Connects the OVN logical switch to the physical network |
| br-ex | The external OVS bridge, enslaved to a physical NIC |
| Physical NIC | Sends the tagged frame to the enterprise switch |
| Enterprise Switch | Existing physical VLAN infrastructure — unchanged by OVN |
Same discipline, same real addressing. This time the VM lives at 192.168.200.10 — a real address on the enterprise VLAN, not a cluster-internal one.
Source 192.168.200.10, MAC 52:54:00:aa:bb:10 — a real, routable address on the enterprise VLAN, not a cluster-internal IP.
The frame crosses the same virtual cable used in every article so far — no difference at this hop.
The pod-local bridge learns the source MAC and forwards toward the veth pair, crossing into the host namespace.
The frame hits the integration bridge. OVN's logical switch and logical port lookups identify this port as connected to a Localnet port, not a regular tenant port.
OVN resolves the Localnet port against its configured bridge mapping — a named provider network (e.g. physnet-dc) that points to a specific external bridge.
Before the frame leaves OVN's logical boundary, OVS injects the VLAN ID (200) into the frame header — this is the only header modification that occurs.
The tagged frame crosses an internal OVS patch port from br-int into the external bridge, br-ex.
The tagged Ethernet frame exits the host entirely through the physical interface enslaved to br-ex.
The upstream physical switch receives the frame, validates the VLAN 200 tag, and forwards it exactly as it would for any bare-metal server on that VLAN.
A Localnet port is a special OVN logical switch port type. Unlike a normal port that connects to a VM or pod, a Localnet port has no workload on the other end — it exists purely to tell OVN "this logical switch also has a door to the physical network."
The connection between the logical world and br-ex is made by a bridge mapping — a named association (like physnet-dc) that OVN's local controller resolves on every node to a specific physical bridge. This is configured once per node, typically via a NodeNetworkConfigurationPolicy (NNCP) — the mechanics of which deserve their own dedicated article.
This is the section that finally answers the question the whole article has been building toward: Localnet is not "another bridge" sitting beside Linux Bridge. It's OVN's own logical network reaching directly into the physical world.
Every other network type in this series either stays entirely inside the kernel (Linux Bridge) or stays entirely inside the overlay (OVN default). Localnet is the hybrid: the workload's port lives in OVN's logical switch, is governed by OVN's control plane, and yet the actual frame that reaches the wire has never been encapsulated at all.
Just like the Linux Bridge article, what leaves the physical NIC here is a native Ethernet frame — with exactly one optional addition.
| Network Type | What Hits the Wire |
|---|---|
| Linux Bridge | Native Ethernet |
| Localnet | Native Ethernet (+ VLAN tag) |
| OVN Default | Geneve-encapsulated |
Kept intentionally concise — the architecture, not the YAML.
A Multus NetworkAttachmentDefinition tells Kubernetes which VMs should attach to the Localnet network. OVN reads that intent, resolves it against the node's configured bridge mapping, and programs OVS flows accordingly. From that point forward, every packet on that port is tagged and handed to br-ex automatically.
| Feature | Localnet |
|---|---|
| Overlay | No |
| Geneve | No |
| VLAN Support | Yes — native 802.1Q |
| Enterprise Integration | Excellent |
| Multi-Tenant Isolation | Limited — shared physical VLAN |
| Network Policies | Depends — enforced only up to the localnet boundary |
| Performance | High — no encapsulation overhead |
| Linux Bridge | OVN | Localnet |
|---|---|---|
| Kernel Bridge | Overlay | Physical Integration |
| Native L2 | Geneve | Native L2 |
| Simple | SDN | Hybrid |
Architecture differences, not feature checklists. The full seven-way matrix lives in the Cloud-Native Networking Architecture Portal.