Architecture Selection Matrix
Eleven criteria, six network types, one interactive table. This alone answers most networking design questions for OpenShift Virtualization.
Not sure which network type fits your platform? We can help evaluate requirements and produce a reference design tailored to your environment.
Click the Packet's Path
This is the question every section on this page answers. Click each hop to see what actually happens there — using the CUDN Localnet path as the example.
tap0 — VM NIC
The kernel TAP device is the virtual cable connecting QEMU to the host's network stack. The VM's guest OS sees this as a normal Ethernet interface — it has no idea what happens after this hop.
Linux Bridge
Linux Bridge is the network type most infrastructure teams reach for first when migrating VMs off VMware or RHV — and for good reason. It behaves exactly like a physical switch: a kernel bridge device (br1, commonly named br-provider) sits inside the pod network namespace, the VM's TAP device plugs into it, and a veth pair crosses into the host namespace where the bridge is enslaved to a physical or bonded NIC. There is no overlay, no OVN logical switch, no Geneve encapsulation — just a flat L2 segment exactly like the one the VM used to live on.
This is precisely why it's the right first choice for lift-and-shift migrations: the VM's guest OS doesn't need to know anything changed. ARP broadcasts, GARP-based failover, and live migration all work exactly as they did on the old platform, because the underlying L2 semantics are identical.
The Packet Walk
Outbound traffic from the VM follows a fixed hop sequence: VM eth0 → tap0 → Linux Bridge (br1, inside virt-launcher pod) → veth pair → host network namespace → host NIC (ethX/bond0, possibly VLAN-tagged) → physical switch → datacenter network. Every hop is a real, inspectable Linux networking primitive — you can run brctl show or bridge link directly on the node and see the exact same topology described here.
Best Practices
✅ Do
- Use a dedicated NetworkAttachmentDefinition per bridge to keep VLAN tagging explicit
- Pin bridge MTU to match the physical switch trunk configuration
- Document which physical NIC each
br-providerbridge maps to per node
❌ Common Mistakes
- Forgetting NetworkPolicy doesn't apply — Linux Bridge traffic bypasses OVN entirely
- Mismatched VLAN tagging between nodes causing intermittent VM connectivity
- Assuming live migration "just works" without validating bridge naming consistency across nodes
Troubleshooting
The most common Linux Bridge issue in production is a VM that can reach some hosts on the VLAN but not others. This is almost always a bridge/NIC naming mismatch between nodes — check that the NodeNetworkConfigurationPolicy (NNCP) that creates the bridge maps to the identical physical interface on every node in the pool, not just the one it was tested on.
OVN-Kubernetes
OVN-Kubernetes is the network controller — not the network engine. That distinction matters more than almost anything else on this page. OVN is Open Virtual Network, an SDN platform that provides logical switches, logical routers, ACLs, NAT, DHCP, and distributed routing as primitives. OVN-Kubernetes is the Kubernetes CNI that automatically translates Kubernetes objects — Pods, Services, Namespaces, NetworkPolicies — into those OVN primitives, without any manual ovn-nbctl commands.
The translation chain is the single most useful mental model for troubleshooting: Kubernetes Object → OVN-Kubernetes Controller → OVN Logical Object → OVS Flow → Packet Forwarding. Once you can trace any Kubernetes object down that chain, you can debug almost any OVN-Kubernetes issue from first principles instead of guessing.
Distributed Routing & The Join Switch
Unlike a traditional network with a central router, OVN's ovn_cluster_router is logically one router but runs locally on every node. When Pod A on Node 1 talks to Pod B on Node 2, the routing decision happens entirely on Node 1 — the packet is routed across a hidden internal L2 segment called the join switch, which triggers Geneve encapsulation, then decapsulates and delivers on Node 2. No central bottleneck, no single point of failure.
EgressIP & BGP
EgressIP is implemented as router policy, not NAT at the source. A priority-100 logical router policy reroutes matching pod traffic to a designated egress node's join-switch IP; the actual SNAT happens on that node's gateway router (GR_<node>). For clusters exposing pod/VM networks directly to a physical fabric, BGP integration via FRRouting lets OVN-Kubernetes advertise pod CIDRs and EgressIPs to a provider router — the foundation for eventual no-overlay, EVPN-based deployments.
Best Practices
✅ Do
- Use
allow-relatedACLs for NetworkPolicy so return traffic is automatically permitted via connection tracking - Design EgressIP pools with at least two nodes for ECMP failover
- Monitor Southbound DB size on very large clusters — it stores full operational state
❌ Common Mistakes
- Assuming EgressIP does SNAT on the source node — it doesn't, SNAT happens on the egress node
- Confusing the Northbound DB (intent) with the Southbound DB (operational state) when debugging
- Not accounting for Geneve encapsulation overhead in MTU planning
OVN Object Model
Six primitives compose every OVN topology: Logical Switch (L2 broadcast domain), Logical Router (distributed L3), ACL (stateful firewall), NAT (SNAT/DNAT/floating IP), Load Balancer (connection-tracked VIP→backend), and DHCP options (answered locally by OVS, no server process). Every Kubernetes object you create maps to one or more of these.
CUDN Localnet
Localnet is the hybrid answer to a question every OpenShift Virtualization migration eventually asks: "Can I keep my existing physical VLANs but still get NetworkPolicy?" A Localnet port on an OVN logical switch does exactly this — traffic still enters OVS br-int and gets full ACL/NetworkPolicy treatment, but instead of Geneve-encapsulating to another node, it exits directly onto a physical VLAN via br-ex and the physical NIC.
This is the network type most enterprises land on for VM workloads that need to be reachable from existing datacenter infrastructure using their own IPs — no NAT, no overlay, but still governed by Kubernetes-native policy.
Outbound Packet Flow
Confirmed hop-by-hop from production testing: VM eth0 → tap0 → Linux Bridge (inside virt-launcher pod) → veth pair → OVS br-int → OVN Logical Switch (localnet port, VLAN 200 tagged) → OVS br-ex → physical NIC (ens5f0) → physical switch (VLAN 200 access/trunk). Return traffic reverses the exact same path: the physical switch delivers the VLAN-tagged frame to the NIC, br-ex receives it, br-int strips the VLAN tag and applies OVN metadata, and the localnet port forwards it to the destination veth.
Best Practices
✅ Do
- Confirm the physical switch port is configured for the exact VLAN the localnet NAD specifies
- Use NetworkPolicy from day one — it works here unlike Linux Bridge
- Keep localnet NAD names consistent across environments for GitOps portability
❌ Common Mistakes
- Forgetting that Localnet has no overlay — MTU must match the physical network exactly
- Assuming Localnet works identically across all nodes without verifying uplink NIC naming
User Defined Networks (UDN)
A User Defined Network creates an entirely isolated OVN topology — its own logical switch, its own segment of the cluster router — scoped to a single namespace. UDNs come in two flavors: L2, which spans all nodes as one flat overlay broadcast domain (required for VM live migration and GARP-based failover), and L3, which gives each node its own subnet behind a router hop (fine for stateless pods, wrong for VMs that migrate).
The distinction matters enormously for OpenShift Virtualization: choosing UDN L3 for a VM workload silently breaks live migration and GARP-based IP takeover, because the VM's IP would need to change subnets when it moves between nodes.
Best Practices
✅ Do
- Always choose UDN L2 for any namespace hosting VMs
- Use UDN L3 only for pure pod workloads that don't need L2 broadcast semantics
❌ Common Mistakes
- Defaulting to L3 for "better scalability" without checking if VMs are present
- Assuming UDN isolation extends to Localnet-attached interfaces — it doesn't by default
Cluster User Defined Networks (CUDN)
CUDN extends the UDN model from a single namespace to a set of namespaces sharing one isolated OVN topology — useful when several teams' namespaces should be network-isolated from the rest of the cluster but still able to reach each other directly, such as a shared services tier or a multi-tenant application platform where "tenant" means a group of namespaces, not just one.
CUDN Localnet (covered in Section 06) is the specific CUDN variant that bridges this isolated topology to a physical VLAN — the combination that most enterprise VM migrations actually deploy in production.
SR-IOV
SR-IOV bypasses the entire software networking stack. A physical NIC (the PF, physical function) exposes multiple lightweight Virtual Functions (VFs), each of which is passed directly into a VM via PCI passthrough. There is no OVS, no bridge, no kernel switching — the VM's guest driver talks almost directly to the NIC hardware. This is the only network type on this page with genuinely near-zero performance overhead, which is exactly why it's the standard for telco UPF and other line-rate workloads.
The tradeoff is total: no OVN, no NetworkPolicy, no tenant isolation, and — critically — complicated live migration, because a VF is tied to a specific physical NIC on a specific node. Migrating a VM with an attached VF requires either detaching and reattaching the VF on the destination node or accepting a connectivity gap.
Best Practices
✅ Do
- Plan VF pools per node explicitly — don't assume even distribution
- Pair SR-IOV with a secondary Multus network, not as the primary pod network
❌ Common Mistakes
- Expecting live migration to work the same as Linux Bridge or OVN — it doesn't without extra tooling
- Forgetting NetworkPolicy silently does nothing on SR-IOV interfaces
macvlan
macvlan creates a virtual interface with its own MAC address directly on top of a physical NIC — lighter weight than a full Linux Bridge, with lower overhead, but with one important limitation: macvlan sub-interfaces on the same physical NIC often cannot communicate with each other directly in bridge mode, and the host itself typically cannot reach macvlan children without a workaround. This makes it a poor fit for anything requiring rich intra-host communication, but a reasonable fit for simple, single-purpose VM or pod attachments that mainly talk outward to the physical network.
Production Design Patterns
Real-world deployment shapes, matched to the network type that actually fits — with the trade-offs stated plainly.
Don't see your deployment shape here? Every pattern above started as a one-hour conversation about actual requirements.
Architecture Maturity Model
Networking requirements evolve as your platform scales. Here's how the right answer changes at each stage.
Decision Tree — Which Network Type Do I Need?
Follow the questions. Every path ends in a concrete recommendation, not a maybe.
Every branch on this tree represents a real trade-off we've navigated before. We can walk your specific environment through this decision live.
Packet Walk Library
Every networking topic on this page answers one question: how does the packet actually travel? This is the library of every packet walk we've documented.
Interactive Architecture Gallery
Every diagram on this page, in one place. Click to zoom fullscreen.
Download Center
Take the reference material with you.
Frequently Asked Questions
Want to Master All Seven Networking Options?
Every architecture on this page is covered as a full packet-walk deep dive in our guided learning curriculum — six articles, one packet at a time.
Explore Learning Path →Need Help Designing Your Networking Architecture?
One conversation can save months of rework. Bring your current topology — we'll map it against every option on this page.