1. Home Page

1.1 Use cases

  • High-Performance Bare Metal Workloads: Leveraging ECMP (Equal-Cost Multi-Path) to provide linear bandwidth scaling and eliminate hardware throughput bottlenecks.

  • Next-Gen Telco & Edge Deployments: Native Dual-Stack (IPv4/IPv6) support for 5G Core functions, ensuring high-throughput, low-latency traffic handling at the network edge.

  • Geographic Traffic Optimization: Directing traffic to the topologically nearest Red Hat OpenShift cluster via OSPF External Type 1 (E1) redistribution, enabling Zero-Touch convergence and automated site failover.

  • TCO Optimization: Significant reduction in Total Cost of Ownership by eliminating specialized load-balancing hardware and licensing, while streamlining Day 2 operations through unified network control plane management.

1.2 The story behind this solution pattern

  • Historically, network traffic relied on centralized hardware load balancers, creating architectural bottlenecks and significant operational costs.

  • Transitioning to MetalLB Layer 3 (BGP), integrating load-balancing intelligence directly into the OpenShift Virtualization control plane, was identified as the path to modernize infrastructure with the following benefits:

    • By advertising Virtual IPs as NLRI (BGP), application endpoints are treated as native subnets with a significantly reduction of the Total Cost of Ownership (TCO).

    • Redistributing BGP routes into OSPF (or other IGPs) removes the "Full Mesh" iBGP requirement, allowing the infrastructure to scale horizontally without configuration bloat.

    • DR shifts to native network re-convergence

    • Dual-stack (IPv4/IPv6) compatible architecture based on a self-healing network fabric.

1.3 The Solution

  • The BGP loadBalancer insfrastructure utilizes MetalLB in Layer 3 (BGP) mode as a foundational component.

  • This approach leverages the reconvergence capabilities of the network infrastructure Control Plane, where the BGP protocol of the MetalLB in Layer 3 is enabled (Figure 1) and the accesses to the Virtual IP addresses of the applications are granted via loadBalancer service.

  • MetalLB in Layer 3 mode (BGP mode) within an OpenShift Virtualization Cluster enables the allocation of External IP addresses for OpenShift Load Balancer services connected to virtual machines (service’s  endpoints).

This approach does not support VMs connected directly to customer VLANs where BGP advertisement occurs at the infrastructure level (e.g., on customer routers acting as the default gateway for those specific VLANs), rather than within OpenShift Virtualization.

  • MetalLB advertises external IP addresses as Network Layer Reachability Information (NLRI composed by Network Prefix and Network Length) to the network’s control plane via BGP.

  • This feature facilitates the deployment of scalable, highly available network services, including those based on dual-stack (IPv4 and IPv6).

  • The implementation of a Disaster Recovery architecture based on MetalLB in Layer 3 mode (BGP mode) offers a cost-effective alternative to traditional hardware load balancing solutions.

  • This approach leads to a significant reduction in the total cost of ownership of the infrastructure due to the following advantages:

    • The external load balancer (LB) is no longer necessary in the Disaster Recovery setup based on the BGP architecture (Figure 1).

    • This is because load balancing functionality is now managed by the OpenShift Load Balancer Services with external IP addresses, which are directly advertised through the BGP protocol of the MetalLB in Layer 3 mode.

    • The Load Balancers are no longer necessary for Disaster Recovery based on the BGP load balancer architecture (Figure 1).

    • In this scenario, the reachability of External IP addresses associated with the OpenShift Load Balancer Service is maintained through the reconvergence capabilities of the Network Control Plane.

  • The adoption of a Network Topology where the External IP Addresses assigned to the LoadBalancer Services and learned from the External BGP routers are redistributed, towards an Interior Gateway Protocol (OSPF in Figure 1), eliminates the complexities associated with the full mesh requirement of the iBGP protocol.

      Figure 1 - Modernizing Disaster Recovery: from traditional Hardware Load Balancers to an Integrated, BGP load balancer architecture.

Figure1 Modernizing Disaster Recovery lb

LB will remain relevant in Business Continuity architectures that require an RTO (Total Downtime) of zero. In such cases, different sets of IP Address Pools are assigned to the MetalLB of the OpenShift Virtualization Clusters to grant the scenarios where the VMs operate in an active-active mode (Figure 2)

      Figure 2 - Modernizing Business Continuity: from traditional Hardware Load Balancers to an Integrated, BGP load balancer architecture.

Figure2 Modernizing Business Continuity