OpenShift 4.22 EVPN: Connecting User-Defined Networks to Enterprise Fabrics
A practical architecture view of BGP EVPN for primary ClusterUserDefinedNetworks—and the routing, isolation, and operational questions to resolve before production.
A workload can keep its IP address after a move and still lose connectivity. The reason is simple: an address is only useful when the surrounding network knows how to reach it—and when the path is permitted.
That distinction matters when enterprises move virtual machines or applications onto OpenShift while trying to preserve established network boundaries. OpenShift Container Platform 4.22 adds BGP Ethernet VPN (EVPN) support for primary cluster-scoped user-defined networks. Used in the supported design, it gives a ClusterUserDefinedNetwork (CUDN) an EVPN control plane for integration with an external data-center fabric.
Why this matters beyond the cluster
OpenShift networking and enterprise data-center networking solve related but different problems. The cluster needs to connect pods and virtual machines, apply workload-level controls, and handle changing placement. The external fabric needs to move traffic between network segments, enforce routing boundaries, and remain predictable during failures.
Without a designed connection between those domains, a modernization project can create parallel network models: one for the legacy environment and another for the new platform. Teams then have to reconcile address plans, routes, segmentation, and troubleshooting practices across both.
EVPN provides a standards-based way to exchange Layer 2 and Layer 3 reachability for supported user-defined networks. The benefit is not “automatic networking.” It is a more direct integration point between the workload network and an existing EVPN fabric, provided both sides agree on the design.
A realistic scenario: moving a business application
Imagine a business application running on virtual machines in an existing data center. It depends on a specific subnet, communicates with shared services, and has tightly controlled paths to databases and upstream systems. The organization wants to run the workload on OpenShift Virtualization, but changing application addresses and every dependent firewall or routing rule would increase migration risk.
A primary user-defined network can provide a deliberate network segment for the workload. With the supported BGP EVPN design, that network can participate in an external EVPN fabric. This can help preserve network relationships—but only if address ownership, routing policy, segmentation, and the migration method are planned together.
EVPN in plain language
The simplest way to remember it is: BGP EVPN tells the network what is reachable; VXLAN carries the traffic through the overlay. They work together, but they are not the same function.
- BGP is the routing protocol used to distribute reachability information between participating peers.
- EVPN defines how Layer 2 and Layer 3 reachability is represented and advertised through BGP.
- VXLAN encapsulates traffic so logical network segments can be carried across an IP underlay.
- VRFs provide separate routing contexts. MAC-VRF and IP-VRF concepts support Layer 2 and Layer 3 network separation in EVPN designs.
- OVN-Kubernetes and user-defined networks provide the OpenShift-side network constructs. The 4.22 EVPN capability discussed here applies to primary cluster-scoped CUDNs, not every network in a cluster.
It is not EVPN versus VXLAN. EVPN is the control-plane mechanism; VXLAN is a common data-plane encapsulation. Nor is it a replacement for firewall policy, network policy, identity controls, or a carefully designed routing boundary.
Architecture and runtime flow
At a high level, a workload sends traffic through its OpenShift user-defined network. The OpenShift-side EVPN/VXLAN function participates in the overlay, while BGP EVPN exchanges relevant reachability with the external fabric. Fabric routers then forward traffic according to their forwarding state and configured policies.
The supported OpenShift 4.22 design also depends on enabling route advertisements and configuring the documented gateway behaviour. The precise prerequisites and required network resources should be reviewed in the version-matched product documentation rather than inferred from a generic EVPN diagram.
Control plane: share reachability
BGP EVPN communicates overlay reachability between OpenShift’s participating network components and the external fabric. Network identifiers, route targets, peer relationships, and route policies must align with the intended segmentation model. A route being advertised is not the same as every destination being reachable or authorized.
Data plane: forward packets
VXLAN carries encapsulated workload traffic across the IP underlay. The underlay must have the required reachability between tunnel endpoints, sufficient MTU headroom and a resilient path design. If encapsulated traffic is dropped or the return path differs from the forward path, a healthy control plane may not be enough to restore application connectivity.
Isolation boundary: keep tenants separate
EVPN and VRF constructs help express logical separation, but isolation is an end-to-end property. Namespace selection, CUDN association, route targets, import/export policy, external ACLs and workload-level policy all need to support the same intent. Treat each as a separate control to validate, not as a substitute for the others.
What EVPN changes—and what it does not
| Approach | Useful when | Important trade-off |
|---|---|---|
| Primary CUDN with EVPN | A supported primary cluster user-defined network needs integration with an external BGP EVPN fabric. | Requires compatible fabric design, peer and route policy planning, and the documented OpenShift prerequisites. |
| CUDN with BGP route advertisements | Workload subnet reachability needs to be advertised through BGP without adopting the EVPN transport model. | Route advertisement alone does not provide the same EVPN overlay integration semantics. |
| Default cluster network | Standard pod connectivity inside the cluster is sufficient and external workload-level network extension is not required. | Do not assume pod addresses are directly reachable from outside the cluster by default. |
| External gateway or routed integration | A clear routing boundary or existing gateway architecture fits the application and security requirements. | May introduce another forwarding or policy boundary and can require explicit route and address design. |
These are architectural choices, not a universal ranking. The right option depends on the required connectivity model, the existing fabric, workload constraints, and the operational capabilities of the team.
A safer implementation lifecycle
Production readiness comes from treating the network as a shared contract between platform and fabric teams—not as a feature toggle.
Map dependencies and current reachability
Inventory workload subnets, consumers, required flows, address overlaps, external services, and the current segmentation model. Identify whether the target is a primary cluster-scoped CUDN and confirm the product version and topology are in scope.
Agree on routing and ownership
Define peer relationships, autonomous system boundaries, VNI and route-target conventions where applicable, route import/export policy, failure domains and responsibility for each network boundary. Resolve overlapping address spaces before onboarding workloads.
Establish the supported OpenShift and fabric integration
Validate documented prerequisites and required networking resources with the platform and network owners. Confirm that the external fabric supports the intended EVPN model and that the chosen CUDN is associated with the correct workload scope.
Enforce the intended isolation
Review namespace selectors, VRF boundaries, route policies, ACLs, network policies and management access. Verify both allowed and denied traffic, including paths between tenants and toward shared services.
Test the complete path, not just route presence
Test forward and return traffic, name resolution, MTU-sensitive flows, application dependencies, node and peer failure scenarios, and expected behaviour during workload relocation. Capture a baseline before moving production traffic.
Make ownership and observability explicit
Agree on route-state monitoring, alerts, change control, escalation paths, and rollback criteria. Keep evidence of the expected route and traffic behaviour so incidents can be diagnosed across platform and network teams.
What EVPN protects—and what it does not
EVPN can help distribute reachability for the supported overlay network and work with VRF-based segmentation. It does not automatically provide application-layer authorization, encrypt workload traffic, validate application health, or eliminate the need for external firewall policy.
| Concern | What EVPN contributes | What still needs a separate control |
|---|---|---|
| Reachability | Distribution of Layer 2 and Layer 3 overlay reachability through BGP EVPN. | Correct route policy, underlay reachability, return paths and application testing. |
| Segmentation | Support for distinct logical routing contexts and network identifiers. | Consistent selectors, route-target policy, ACLs, network policy and access reviews. |
| Confidentiality | Not a traffic-encryption mechanism by itself. | Encryption in transit where required, plus key and certificate lifecycle management. |
| Availability | Can participate in a resilient fabric design. | Redundant peers and paths, capacity, failure testing, monitoring and recovery procedures. |
| Migration continuity | Can help retain intended network connectivity in a compatible design. | Address ownership, duplicate-IP prevention, dependency validation, and cutover planning. |
Common mistakes and trade-offs
- Assuming every UDN is eligible. The documented feature is for primary cluster-scoped CUDNs. Validate the exact network type and release support first.
- Confusing route advertisement with permission. A route can exist while a firewall, ACL, or workload policy blocks the application flow.
- Overlooking MTU. VXLAN adds encapsulation overhead. An underlay MTU that is too small can cause failures that appear only on larger packets or particular protocols.
- Ignoring return-path symmetry. Forward reachability does not prove the response follows a valid path through the expected policy boundaries.
- Using inconsistent VNI or route-target conventions. Mismatched network identifiers or import/export policy can prevent expected reachability or undermine separation.
- Assuming network parity means application parity. Preserving an IP address does not migrate dependencies, firewall state, DNS behaviour, load-balancer configuration, or operational ownership.
- Skipping failure tests. Normal-state reachability says little about how routes and traffic behave when a peer, node or fabric path is unavailable.
Troubleshooting by symptom
| Symptom | Potential cause to investigate | Useful diagnostic direction |
|---|---|---|
| The network is not accepted or EVPN transport is unavailable. | The referenced transport resource is missing, rejected or inconsistent with the CUDN association. | Start with the relevant resource conditions and the documented prerequisites before investigating application traffic. |
| Routes appear on one side but not the other. | BGP peer state, route policy, route targets, network selectors or advertised scope do not match. | Compare expected and observed route state at both the OpenShift and fabric boundaries. |
| Small requests work but larger transfers fail. | MTU mismatch or encapsulation overhead may be causing packet drops or fragmentation issues. | Check end-to-end MTU assumptions and packet behaviour across the overlay and underlay. |
| One direction works; responses time out. | Missing return route, asymmetric forwarding, ACLs or stateful policy may be involved. | Trace the forward and return paths independently and compare policy at each boundary. |
| Connectivity works but tenant isolation is wrong. | Overbroad route import/export, selectors, VRF association or external policy may expose an unintended path. | Test prohibited flows explicitly; do not use successful allowed traffic as evidence of isolation. |
| A workload move causes an outage. | Address ownership, stale reachability, dependency assumptions or migration constraints may not have been validated. | Correlate workload placement changes with route updates, neighbour state and application-level health. |
These are diagnostic hypotheses, not claims that every symptom has a single cause. Start by locating the failure boundary: workload, OpenShift network, BGP EVPN control plane, VXLAN data plane, underlay, or external policy.
Frequently asked questions
What does EVPN do in OpenShift 4.22?
OpenShift 4.22 documents BGP EVPN support for primary cluster-scoped user-defined networks. It lets a supported CUDN use an EVPN control plane to integrate with a data-center network.
Is EVPN the same as VXLAN?
No. EVPN is a control-plane mechanism for advertising reachability; VXLAN is an encapsulation used to carry overlay traffic. They are commonly used together.
Does EVPN work with every OpenShift network?
Do not assume so. The documented OpenShift 4.22 capability is scoped to primary cluster-scoped CUDNs. Confirm the exact network type and prerequisites in the documentation for your release.
Does EVPN preserve a VM’s IP address during migration?
EVPN can support network designs that preserve logical connectivity, but it does not guarantee that an address can safely move. Address ownership, persistent addressing, routing, and the supported migration path all need validation.
Does EVPN replace network policies or firewalls?
No. EVPN distributes reachability. Workload policies, external ACLs, and firewall controls remain important for enforcing which traffic is allowed.
What should be checked before enabling BGP EVPN?
Confirm release support, documented gateway and route-advertisement prerequisites, peer and fabric compatibility, route-policy boundaries, network identifiers, MTU, security controls, and operational ownership.
The takeaway: treat reachability as a contract
OpenShift 4.22 BGP EVPN is most useful when an enterprise needs a supported primary user-defined network to participate in an existing EVPN fabric. Its value is the ability to integrate network reachability through established protocols—not a promise that routing, security, and migration complexity disappear.
Design the control plane and data plane separately, verify isolation independently, and test failure conditions before production cutover. That discipline is what turns an architectural capability into a dependable operating model.
