live wire
▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM▸AI · Red Hat documents usage-based admission fair sharing for Kueue 1.4 on OpenShiftRed Hat Developer▸AI: Red Hat maps governed firewall changes from ServiceNow through Ansible and two human approval gatesRed Hat Developer▸CLUSTER MGMT · ACM 2.17 makes Submariner 0.24 GA with Important-rated fixesRed Hat Errata▸PLATFORM · Red Hat makes on-premises Lightspeed recommendations GA for Satellite 6.18Red Hat Errata▸SECURITY · Red Hat Hardened Images updates Tomcat 10 for nine authentication, access-control and DoS flawsRed Hat Errata▸AI · Open Data Hub 3.6.0 EA1 bundles Trainer, MLflow and llm-d componentsOpen Data Hub▸AI · Speculators 0.6.0 adds P-EAGLE parallel drafting for vLLM speculative decodingRed Hat Developer▸SECURITY · OpenShift 4.17.57 fixes seven Go and TLS CVEs in an Important-rated updateRed Hat Errata▸AI · Red Hat benchmarks local LLM guardrails with EvalHub, exposing regex accuracy and latency trade-offsRed Hat Developer▸AI · Red Hat maps silent tool-call failures across agentic pipelinesRed Hat▸API · Kuadrant 1.5.3 adds GRPCRoute policies and developer-portal API-key workflowsKuadrant▸AI · (Aug 25) IBM releases Apache-2.0 Granite 4.2 reasoning models in 3B, 8B and 30B sizesIBM Research▸JAVA · Red Hat build of Quarkus 3.33.3.SP1 fixes 13 CVEs in an Important-rated updateRed Hat errata▸AI · vLLM moves Kimi K2 RL weight sync across 384 H100s in 7.53 seconds (Aug 22)vLLM
upstreambeat.ai
guidePLATFORM

Red Hat’s BGP-EVPN pattern stretches legacy networks into OpenShift Virtualization

The OpenShift 4.22 design preserves VM addresses across staged migrations, but its bare-metal and networking constraints demand careful lab validation.

Legacy network versus OpenShift EVPN migration with unchanged VM identity.
AI-generated illustration
By The News Desk· Sep 3, 2026the quick take — two AI hosts, this story only

Red Hat has published a worked configuration for extending an existing Layer 2 data-center network into Red Hat OpenShift Virtualization with BGP Ethernet VPN. The pattern is aimed at staged VM migrations: an imported VM can boot on OpenShift with its existing IP and MAC addresses while the rest of its application remains on the legacy platform.

The design uses a primary ClusterUserDefinedNetwork (CUDN) carried over a VXLAN overlay. FRRouting supplies the BGP-EVPN control plane, while OVN-Kubernetes connects the cluster network to the external fabric. Red Hat’s OpenShift 4.22 documentation describes both MAC-VRF mode for stretched Layer 2 segments and IP-VRF mode for routed Layer 3 connectivity.

What the walkthrough builds

The Red Hat Developer lab starts with a three-node bare-metal OpenShift cluster whose nodes each have a second physical interface connected to a provider network. The procedure enables FRR and route advertisements in the Cluster Network Operator, assigns node addresses for VXLAN tunnel endpoints, and creates four linked resources: FRRConfiguration, VTEP, RouteAdvertisements, and ClusterUserDefinedNetwork.

The example gives the CUDN a MAC-VRF and VNI 100. An external FRR router imports the VM’s MAC and IP reachability through EVPN. After the VM moves between OpenShift nodes, the external router learns the new tunnel endpoint while the VM keeps the same MAC address. That is the operational point of the pattern: migration changes where the workload runs without forcing a simultaneous change to its network identity.

Who should use it

The pattern is relevant to platform teams moving VM estates gradually into OpenShift Virtualization, especially where tenant networks overlap or applications depend on fixed addresses. EVPN can map isolated CUDNs to corresponding route targets in the existing fabric and replace separate VLAN interfaces and per-VRF BGP sessions with a shared multiprotocol BGP session.

It is not a universal attachment method. OpenShift 4.22 supports BGP-EVPN CUDNs only on bare-metal clusters. The documented configuration also requires routingViaHost: true and global IP forwarding. IPv6 tunnel endpoints, IPsec, EgressIP and several other networking features are unsupported; NodePort, External IP and LoadBalancer services have additional reachability limits.

What to test first

Teams should reproduce the pattern on a non-production cluster before attaching a migration network. Validate BGP neighbor state, VTEP allocation, route-target and VNI uniqueness, tenant isolation, and MAC mobility during a VM move. The OpenShift documentation caps the combined MAC-VRF and IP-VRF instances at 4,094 per tunnel endpoint and fixes VXLAN transport to UDP port 4789, constraints that belong in the design review rather than the rollout window.

The useful contribution here is not a claim that EVPN removes migration risk. It is a concrete, inspectable way to separate the VM move from the network renumbering project—and a list of platform boundaries teams can test before doing either in production.

sources

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.

    more from the desk