Understanding Keepalived Routing Principles: NAT, TUN, and Direct Routing (DR) Explained

Preface

In the previous article we introduced the underlying principles of Keepalived; this middle part continues the series by focusing on Keepalived’s routing principles.

The author uses a personal anecdote about working as a junior food runner in a restaurant to create an intuitive analogy for the routing process.

1. Restaurant Roles

The restaurant has three main roles:

Waiter : records customer orders, timing, and serves dishes; can be seen as multiple clients.

Food Runner : notifies the kitchen, marks dishes, and delivers food; represents the Keepalived component.

Chef : cooks and plates dishes; represents the real backend server.

The food runner decouples waiters from chefs, illustrating the separation of client requests from backend processing.

Process flow:

Customer places an order.

Waiter records the order and desired serving time.

Waiter hands a copy of the order to the food runner.

Food runner loudly notifies chefs of the dishes to prepare.

Chef prepares the dish; if ingredients are missing, the chef informs the runner, who informs the waiter.

Chef hands the finished dish to the runner.

Runner marks the dish as completed.

Runner delivers the dish to the waiter.

Waiter marks the dish as served.

Waiter serves the dish to the customer.

This mirrors a client request being forwarded to Keepalived, which forwards it to the real server, receives the response, and returns it to the client.

2. Initial Exploration of Keepalived Routing Schemes

2.1 Why a Routing Scheme Is Needed

After selecting a real server via Keepalived’s load‑balancing algorithm, two additional steps are required: forwarding the request to the chosen server and returning the processed result to the client.

Keepalived supports three routing schemes: NAT, TUN, and Direct Routing (DR).

2.2 Where the Configuration Resides

The routing mode is configured in keepalived.conf via the lb_kind parameter, which can be set to NAT , DR , or TUN . The load‑balancing algorithm is set with lb_algo (e.g., wrr for weighted round‑robin).

2.3 LVS Architecture

Keepalived leverages Linux Virtual Server (LVS). The architecture consists of a front‑end load balancer (LB) and multiple real servers (RS). The LB forwards traffic, while RS processes requests and returns responses.

3. Deep Dive into Keepalived Routing Schemes

3.1 NAT Routing Scheme

NAT (Network Address Translation) enables private IPs to access external networks and allows external users to reach internal hosts.

In the restaurant analogy, NAT corresponds to the standard order‑to‑dish flow where waiters hand orders to the runner, who notifies chefs, and chefs return dishes via the runner.

Typical LVS setup includes two NICs:

eth0 网卡 -> 公网 VIP -> 外部网络
eth1 网卡 -> 私有 VIP -> 交换设备 > 内网网络

Key steps:

Client sends request to the public VIP (e.g., 10.1.2.88 ).

Main LVS router replaces the destination address with a NAT VIP (e.g., 192.168.56.88 ).

The NAT VIP resides in the same LAN as the real servers, allowing the request to be load‑balanced to a chosen server.

LVS rewrites the packet’s destination IP and port to the real server’s.

Real server processes the request and sends the response back to the LVS router.

LVS translates the source back to the public VIP and forwards the reply to the client.

Clients only see the public VIP; they are unaware of the NAT VIP or real server IPs.

3.2 TUN Routing Scheme

3.2.1 Bottleneck of NAT

When traffic is heavy, the single runner (LVS) becomes a bottleneck because all packets must pass through it for address translation.

TUN solves this by allowing real servers to send responses directly to clients, bypassing the LVS for the return path. This requires real servers to have external network connectivity.

In the restaurant analogy, the chef hands the dish directly to the waiter, eliminating the runner.

3.2.2 Details of TUN

TUN stands for tunneling. It encapsulates the original IP packet inside another IP packet, adding a new source and destination address.

Steps:

Encapsulate the original packet.

Add new source/destination IP and ports.

This allows the packet to travel through an IP tunnel to the real server, which then replies directly to the client.

3.3 Direct Routing (DR) Scheme

DR also forwards client requests to a real server, but the real server replies using the shared VIP address without any tunneling.

Key characteristics:

Both LVS and real servers must reside in the same LAN.

No IP tunnel is created.

The VIP is shared among the LVS router and all real servers.

Real servers set the source IP to the VIP when sending responses.

Because the LVS and servers share a broadcast domain, ARP requests for the VIP are answered only by the LVS (Director Server).

4. Comparison of the Three Modes

The article includes a comparison diagram and recommends the DR mode for most scenarios.

Easter Egg 1

A reader asked whether the master node sends VRRP or ARP broadcast packets to the backup. The answer clarifies that the master sends VRRP advertisements containing priority information and also broadcasts ARP requests to announce its IP/MAC mapping.

vrrp.c
vrrp_send_adv(vrrp_t * vrrp, uint8_t prio)

The function vrrp_send_adv is invoked with the effective priority field.

Easter Egg 2

Photos from the author's restaurant job are shown, adding a personal touch.

About the Author

The author has eight years of internet development experience, specializing in micro‑services, distributed systems, and architecture design, and is an active contributor to several technical communities.

He offers technical Q&A, resume reviews, and a 500‑member technical group, and provides various downloadable resources (Spring Cloud, distributed algorithms, JVM training, Elasticsearch).