Building multiple software-defined networks inside one cluster. This article doesn't follow a packet — it follows a network, from the moment an architect decides one topology isn't enough.
In a traditional OpenShift cluster, every namespace — Finance, Telco, Production, DMZ — shares exactly one thing underneath: the same cluster router, the same logical topology, the same OVN Northbound database entries extended outward. Isolation between them exists at exactly one layer: NetworkPolicy, a set of rules layered on top of a network they all still fundamentally share.
That's sufficient for most workloads. But it starts to strain the moment an architect needs something stronger than a rule that could, in principle, be misconfigured — a Financial Services namespace that must be provably unreachable from a Development namespace, not just policy-blocked from it. Auditors ask about topology. Rules can be changed by anyone with the right RBAC; topology can't be crossed at all.
What if, instead of one shared network with rules layered on top, a namespace could have its own completely separate SDN — its own router, its own switch, its own routing domain? That's exactly what a User Defined Network is.
One compact answer before diving into the architecture.
Get one misconception out of the way immediately: a UDN is not another network interface. It's not Multus. It's not another bridge sitting beside the default one. A UDN doesn't extend the default OVN network — it instructs OVN to build an entirely separate logical forwarding topology that coexists on the same cluster infrastructure: its own logical switch, its own logical router, its own ACLs, its own NAT rules, and its own routing tables, completely separate from the default network's.
A fair question, since Multus has been the go-to answer for "extra networks" in Kubernetes for years. For a primary UDN — the case covered in this entire article — the answer is no: the pod's primary interface attaches directly through OVN-Kubernetes's own CNI, no Multus in the path.
Multus only re-enters the picture for secondary UDN attachments — a pod with an additional interface into a UDN alongside its primary network.
One clarification worth stating precisely, since diagrams can imply more sharing than actually exists: every UDN still connects to the cluster-level routing framework, but only through its own isolated logical objects. Traffic between different UDNs is absent by default — not filtered, absent — unless explicit connectivity is deliberately configured.
Zooming into what "isolated topology" actually means as rows in a database:
Default, UDN-1, and UDN-2 each get their own complete set: Logical Switch, Logical Router, Router Port, Switch Port, ACL, Address Set. Nothing in one column references anything in another — which is exactly why there's no route between them to misconfigure in the first place.
Most explanations stop at "OVN creates an isolated network." Here's what that sentence actually means, mechanically, from the moment a cluster admin applies a UDN manifest.
The user (or cluster admin, for CUDN) submits a UDN manifest. OVN-Kubernetes's controller watches for it and writes new rows into the OVN Northbound database — a new Logical Router, a new Logical Switch, ACLs, and port bindings, all tagged as belonging to this UDN rather than the default network. ovn-northd compiles that intent down to the Southbound database, and each node's ovs-vswitchd reads only the flows relevant to its local pods and installs them as OpenFlow rules.
Zooming out to the full translation chain makes the isolation model click into place.
This is the same translation chain readers of Part 2 already know. What's different isn't the mechanism — it's that this chain now produces a completely separate branch of logical objects, disconnected from the default network's branch at the Northbound database level.
This is the clearest possible statement of the article's core claim: UDN extends the existing architecture — it doesn't replace it.
Once traffic is inside a UDN, forwarding behaves exactly like the default network's distributed routing covered in Part 2 — because mechanically, it is the same distributed routing engine, just scoped to this UDN's own logical router instance.
Pod A sends to Pod B. The frame hits br-int, the UDN's own logical router makes a local routing decision, and — because the destination is on another node — the packet is Geneve-encapsulated and tunneled to Node 2, where it's decapsulated and delivered.
This is where the article earns its place in the series. Most engineers assume UDN isolation works like NetworkPolicy — a rule that blocks traffic. It doesn't.
A pod in UDN-1 cannot reach a pod in UDN-2 — not because a firewall rule blocks it, but because no logical route to it exists at all. There's no shared logical router, no shared logical switch, nothing in the Northbound database connecting the two topologies. Traffic isn't dropped by a policy evaluation; it simply has nowhere to go.
| UDN | CUDN |
|---|---|
| Namespace scoped | Cluster scoped |
| One namespace | Multiple namespaces |
| Team-level isolation | Enterprise-wide segmentation |
| Created by namespace owner | Created by cluster admin |
Put simply: a CUDN is not technically different from a UDN. The underlying OVN objects — logical switch, logical router, ACLs — are built exactly the same way. The difference lies entirely in who creates it and how many namespaces consume the same isolated topology.
| Linux Bridge | Localnet | UDN |
|---|---|---|
| L2 | L2 | L3 SDN |
| Linux bridge | OVN | OVN |
| Physical VLAN | Physical LAN | Virtual topology |
| No overlay | No overlay | Geneve |
| Fast | Moderate | Feature rich |
The full seven-way matrix, including SR-IOV and macvlan, lives in the Cloud-Native Networking Architecture Portal.
Everything covered so far is architecture. Here's where it fits in the operational lifecycle every OpenShift platform team already thinks in.