Red HatMiguel Duarte de Mora Barroso, Valentino UbertiTutorial
The article describes how to extend Layer 2 networks from a legacy data-center fabric into Red Hat OpenShift Virtualization using BGP and EVPN. It uses a three-node OpenShift lab with secondary NICs on a provider network, static IPv4 addressing, a VTEP CR for 172.19.0.0/24, FRRouting peering, and a Layer 2 primary CUDN with VNI 100. The configuration preserves imported VMs’ IP and MAC identities while maintaining isolation for tenant networks that may have overlapping address spaces. In the example, an external FRR router learns the VM MAC through EVPN and reaches 22.100.0.3; after the VM moves from node 3 to node 1, the MAC remains unchanged and the advertised VTEP changes from 172.19.0.102 to 172.19.0.100. The stated result is phased migration with Layer 2 adjacency to legacy application tiers and end-to-end tenant segmentation.
Migrating VMs from legacy bare-metal infrastructure to Red Hat OpenShift Virtualization can disrupt network dependencies, require NAT workarounds, and complicate multi-tenant isolation. The stated goal is to preserve Layer 2 connectivity and security boundaries during phased adoption, including for tenant networks with overlapping IP address spaces.
The configuration enables BGP and FRR in OpenShift, assigns static IPv4 addresses to secondary node NICs, creates a VTEP for the provider-network CIDR, configures FRRouting peering, and creates a Layer 2 primary CUDN with VNI 100. A VM is attached to the CUDN and an external FRR router exchanges its MAC and reachability through BGP EVPN.
Imported VMs can retain their original IP and MAC addresses when booted on the stretched Layer 2 network, allowing communication with application tiers that remain on the legacy platform.
The example uses secondary NIC addresses in 172.19.0.0/24 as VTEP addresses and advertises the CUDN through BGP EVPN with VNI 100.
When the VM moves from node 3 to node 1, its MAC remains unchanged while the external router updates the selected VTEP from 172.19.0.102 to 172.19.0.100.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
ACME uses different domain-control validation methods. tls-alpn-01 works on shared hosting without DNS access; DNS challenges suit wildcard certificates but require external DNS control.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
