Designing High‑Performance Software L4 Load Balancers: Insights from LVS, Google Maglev, and Facebook Katran

Introduction

L4 load balancing (e.g., LVS) operates at the transport layer and primarily forwards traffic; the article focuses on software‑based high‑performance L4 load balancers inspired by large‑scale deployments at Google, Facebook, and other companies.

Limitations of LVS

LVS is built on the kernel netfilter hook, causing packets to traverse a long protocol stack before forwarding, and heavy interrupt handling (e.g., 600 k packets → 100 k interrupts per second) leads to cache misses and performance degradation.

Traditional HA designs using keepalived+VRRP create a master‑backup structure where half of the machines are idle, limiting horizontal scalability.

Forwarding Modes of LVS

LVS supports NAT, DR, TUNNEL, and FULLNAT, each with distinct trade‑offs regarding source IP preservation, VLAN requirements, and scalability.

Google Maglev Load Balancer

Maglev is a software‑defined, highly elastic L4 load balancer that uses a 5‑tuple (src/dst IP, protocol, src/dst port) consistent hash to distribute traffic across many back‑ends.

The algorithm builds a lookup table by assigning each back‑end a preferred position list (permutation) derived from two hash values (offset and skip), ensuring uniform distribution.

Maglev runs on a large distributed system, leveraging ECMP for routing and providing fault‑tolerant traffic distribution.

Facebook Katran

Katran combines XDP and eBPF to process packets in the kernel’s early data path, achieving higher throughput than previous versions.

It adopts an extended version of Google’s Maglev consistent‑hash algorithm, adds lightweight per‑node weighting, and uses an LRU cache for local state to balance lookup latency and memory pressure.

Additional optimizations include RSS for NIC‑to‑CPU affinity and IP‑in‑IP encapsulation for flexible placement of L4 LB and back‑ends.

Designing a High‑Performance L4 Load Balancer

Modern data‑center workloads demand rapid provisioning, elastic scaling, and zero‑downtime; a software‑defined L4 LB built on FD.io VPP accelerated by DPDK can meet these requirements.

DPDK provides user‑space drivers, zero‑copy, batch processing, and hardware‑aware features (DDIO, NUMA, huge pages) to achieve line‑rate packet processing.

VPP runs in user space, supports multiple receive methods, and offers a rich set of routing and switching functions.

Health‑check services continuously verify back‑end health, enabling automatic failover without disrupting active connections.

Horizontal Scaling Techniques

Combining ECMP, BGP, and Maglev consistent hashing distributes traffic across many paths and back‑ends, improving bandwidth utilization and resilience.

L3DSR (Layer‑3 Direct Server Return) overcomes VLAN constraints of DR mode, allowing a single hardware LB to serve many virtual IPs.

Fault Tolerance and HA

Health‑check agents detect failures and trigger soft‑release of primary servers, while runtime switches can disable local state lookups under memory pressure.

Appendix

VPP (originating from the FD.io project) provides a programmable data‑plane for building load balancers, firewalls, IDS, etc.

DPDK accelerates packet processing through polling, user‑space drivers, core affinity, and cache‑aware optimizations.

Netfilter offers hook mechanisms for NAT, filtering, and connection tracking.