Mastering IPVS: Linux Kernel Load Balancing Algorithms & Configuration

IPVS Overview

IPVS is a layer‑4 load balancer that runs in the Linux kernel space, providing functionality similar to user‑space balancers such as Nginx or HAProxy. It forwards client requests to real servers based on scheduling algorithms, offering higher performance than user‑space solutions but limited to layer‑4 traffic.

IPVS Scheduling Algorithms

IPVS decides which real server (RS) should handle a request using one of several scheduling algorithms:

Round Robin (RR): distributes requests evenly by cycling through all RS nodes.

Weighted Round Robin (WRR): assigns weights to RS nodes and distributes traffic proportionally.

Least Connections (LC): sends traffic to the RS with the fewest active connections, ideal for long‑lived connections.

Weighted Least Connections (WLC): weighted version of LC.

Address Hash: maps client IP addresses to specific RS nodes via a hash table.

IPVS Forwarding Modes

After selecting an RS, IPVS can forward packets using three modes:

DR (Direct Routing)

NAT (Network Address Translation)

IP Tunneling

Performance ranking: DR > NAT > IP Tunneling.

DR Mode

In Direct Routing, the load balancer rewrites the destination MAC address to that of the RS while keeping the original IP addresses unchanged. The RS processes the request and sends the response directly to the client, bypassing the load balancer, which yields the highest forwarding efficiency.

Key characteristics of DR mode:

Source and destination IP/port remain unchanged; only the MAC address is altered, so the load balancer and RS must reside in the same subnet.

Each RS must bind the virtual IP (VIP) on its loopback interface to accept packets addressed to the VIP.

The service on the RS must listen on the VIP and the same port as the virtual service.

Responses go directly from RS to client, requiring network reachability between RS and client.

NAT Mode

In NAT mode, both request and response packets pass through the load balancer. The LB performs destination NAT (DNAT) on incoming packets, changing the destination IP to the RS's IP, and source NAT (SNAT) on outgoing packets, replacing the source IP with the VIP.

Key characteristics of NAT mode:

The LB modifies packet addresses (DNAT for requests, SNAT for responses).

The client IP is preserved and visible to the RS.

RS must set its default gateway to the LB's virtual IP so that response packets return via the LB.

LB and RS must be in the same subnet, while the client must be in a different subnet.

IP Tunneling Mode

In IP tunneling, the LB encapsulates the original request inside another IP packet and forwards it to the RS. The RS decapsulates the packet, processes the request (VIP is bound to a TUN interface), and sends the response directly to the client.

Key characteristics of IP tunneling:

LB and RS can be in different subnets, removing the subnet restriction of DR and NAT.

Both LB and RS must support tunneling, and the RS must bind the VIP on a TUN interface.

RS must have Internet access because responses go directly to the client.

Command Demonstration

IPVS is managed via the ipvsadm command, similar to how iptables manages netfilter.

Commands:
  --add-service     -A   Add a virtual service
  --edit-service    -E   Edit a virtual service
  --delete-service  -D   Delete a virtual service
  --clear           -C   Remove all virtual services
  --restore         -R   Read commands from stdin (often used with -S)
  --save            -S   Output current virtual service rules
  --add-server      -a   Add a real server to a virtual service
  --edit-server     -e   Edit a real server
  --delete-server   -d   Delete a real server
  --list            -L|-l List virtual services (add -c to show connections)
  --help            -h   Show help

Options:
  --tcp-service  -t service-address   Define a TCP virtual service (host[:port])
  --udp-service  -u service-address   Define a UDP virtual service (host[:port])
  --scheduler    -s scheduler        Choose a scheduler (rr, wrr, lc, wlc, lblc, lblcr, dh, sh, sed, nq)
  --real-server  -r server-address   Specify the RS address (optional port)
  --gatewaying   -g                 Set forwarding mode to DR (default)
  --ipip         -i                 Set forwarding mode to IP tunneling
  --masquerading -m                 Set forwarding mode to NAT
  --connection   -c                 List current IPVS connections

Environment Preparation

Three VMs (VM1 as LB, VM2 and VM3 as RS) are created in VMware with NAT networking.

Device

IP

client

7.249.241.35

VM1 (LB)

IP: 192.168.81.128

VIP: 192.168.81.100

VM2 (RS1)

192.168.81.129

VM3 (RS2)

192.168.81.130

Enable connection tracking and IP forwarding on the LB:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.vs.conntrack=1" >> /etc/sysctl.conf
sysctl -p

Install ipvsadm on the LB: yum install ipvsadm Add the VIP to the LB's network interface:

# ip addr add 192.168.81.100/24 dev eth0
# ip a s eth0

Create a virtual service on VIP:80 using Round Robin scheduling: ipvsadm -At 192.168.81.100:80 -s rr Add two real servers (RS1 and RS2) with NAT forwarding:

ipvsadm -at 192.168.81.100:80 -r 192.168.81.129:80 -m
ipvsadm -at 192.168.81.100:80 -r 192.168.81.130:80 -m

Verify the configuration:

[root@test ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.81.100:80 rr
  -> 192.168.81.129:80              Masq    1      0          0
  -> 192.168.81.130:80              Masq    1      0          0

Ensure the client can reach the VIP by adding a route to the VMware NAT gateway (192.168.81.1) on the client machine.

Because the environment uses VMware NAT, the client request’s source IP is translated to 192.168.81.1. Add a route on each RS so that response packets are sent back through the LB:

# ip route add 192.168.81.1 via 192.168.81.128 dev eth0

Test the setup: the LB distributes incoming requests to the two RS nodes in a round‑robin fashion.