Operations 17 min read

Three IP Load‑Balancing Methods in Linux LVS: VS/NAT, VS/DR, and VS/TUN Explained

This article explains three IP load‑balancing techniques used in Linux Virtual Server—VS/NAT, VS/DR, and VS/TUN—detailing their architectures, packet‑rewriting processes, configuration examples, performance characteristics, and a comparative analysis of their strengths and weaknesses.

Open Source Linux
Open Source Linux
Open Source Linux
Three IP Load‑Balancing Methods in Linux LVS: VS/NAT, VS/DR, and VS/TUN Explained

Introduction

Previously we described several scalable network service structures that all require a front‑end scheduler. Among scheduler implementation techniques, IP load‑balancing is the most efficient. This article describes three IP load‑balancing techniques—VS/NAT, VS/DR and VS/TUN—their principles, advantages and disadvantages.

VS/NAT

Implements a virtual server by using Network Address Translation (NAT) to combine a group of servers into a high‑performance, highly available virtual server. Most commercial IP load‑balancers such as Cisco LocalDirector and F5 Big/IP use this method.

VS/DR

Implements a virtual server by Direct Routing (DR). The scheduler forwards packets to the selected real server without rewriting the destination IP address; only the MAC address is changed.

VS/TUN

Implements a virtual server by IP tunneling. The scheduler encapsulates the client packet in an IP tunnel and forwards it to the selected real server; the server decapsulates and processes the original packet.

Implementation Framework

System implementation details can be found in the official documentation.

LVS官方文档:</code><code>http://zh.linuxvirtualserver.org/node/58

In Linux kernel 2.0 and 2.2 the TCP/IP stack was modified to intercept, rewrite and forward IP packets, providing three IP load‑balancing techniques and the ipvsadm tool for configuration. In kernels 2.4 and 2.6 the functionality is implemented as a NetFilter module.

Key modules include the VS Schedule & Control Module attached to the LOCAL_IN and IP_FORWARD chains, the VS Rules Table, Connections Hash Table, Stale Connection Collector, Statistics Data, etc. User‑space ipvsadm writes rules via setsockopt() and reads them through the /proc filesystem.

The connection hash table can hold millions of concurrent connections; each entry occupies 128 bytes in kernels 2.2 and 2.4, allowing a 256 MiB scheduler to handle about two million connections. The number of hash buckets can be tuned to reduce collisions.

Each connection records the packet‑sending method (VS/NAT, VS/TUN, VS/DR or local node), state and timeout. States follow the TCP finite‑state machine (e.g., SYN_REC, ESTABLISHED, FIN_WAIT) with configurable timeout values.

Features of IP Virtual Server

All three IP load‑balancing techniques can coexist in one server cluster.

Pluggable connection‑scheduling modules with five algorithms.

Efficient hash function.

Effective garbage‑collection mechanism.

Unlimited number of virtual services, each with its own server pool.

Support for persistent virtual services.

Correct ICMP handling.

Local‑node functionality.

Provides usage statistics.

Three defense strategies against large‑scale DoS attacks.

VS/NAT Details

Because IPv4 address space is scarce, NAT is used to map private internal addresses to public ones. VS/NAT places a scheduler in front of a server pool; the scheduler rewrites the destination IP and port to the selected real server and records the mapping in the connection hash table. Responses are rewritten back to the virtual IP address before being sent to the client.

Timeouts: SYN = 1 min, ESTABLISHED = 15 min, FIN = 1 min, UDP = 5 min. When a connection ends or times out, it is removed from the hash table.

Application‑level protocols that embed IP addresses (FTP, IRC, RSTP, PPTP, etc.) require additional modules to rewrite addresses inside the payload.

Example configuration: traffic to 202.103.106.5:80 is load‑balanced between 172.16.0.2:80 and 172.16.0.3:8000; traffic to 202.103.106.5:21 is directed to 172.16.0.3:21; other ports are rejected.

Packet flow diagrams illustrate request rewriting, server selection, and response rewriting back to the virtual IP address.

VS/TUN Details

VS/TUN uses IP tunneling to encapsulate client packets and forward them to a selected real server. The server decapsulates the packet, processes it, and sends the response directly to the client, keeping the virtual IP address unchanged.

The scheduling and management are similar to VS/NAT, but packet forwarding differs. The TCP state machine follows a half‑connection model.

VS/DR Details

VS/DR is similar to VS/TUN but uses Direct Routing: the scheduler changes only the MAC address of the frame and forwards it to the chosen server without IP rewriting or encapsulation. The server processes the packet and returns the response directly to the client.

Both VS/DR and VS/TUN handle only the request side in the scheduler; responses bypass it, improving throughput.

Comparison of Advantages and Disadvantages

The table below summarizes the pros and cons of the three IP load‑balancing methods.

Note: The maximum number of servers supported by each method assumes a 100 Mbit scheduler with hardware comparable to the backend servers and typical web workloads. Higher‑end hardware (e.g., 1 Gbps NICs) can increase scalability.
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

NetworkingIP load balancingLinux LVSVS/DRVS/NATVS/TUN
Open Source Linux
Written by

Open Source Linux

Focused on sharing Linux/Unix content, covering fundamentals, system development, network programming, automation/operations, cloud computing, and related professional knowledge.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.