Understanding Keepalived Routing Principles: NAT, TUN, and DR Modes Explained

Preface

Hello, I am Wukong. In the previous article we covered the underlying principles of Keepalived; now we continue with its routing principles.

1. Restaurant Roles Analogy

In a restaurant there are three main roles:

Waiter : records orders, tracks serving time, and can be seen as a client sending requests.

Runner (Dish Server) : notifies the kitchen, marks dishes, and represents the Keepalived component.

Chef : cooks and plates dishes, analogous to the real backend server.

The workflow is: customer orders → waiter records → runner notifies → chef cooks → runner delivers → waiter serves.

This mirrors how a client request is passed to Keepalived (runner), which forwards it to a real server (chef) for processing, then returns the result.

2. Initial Exploration of Keepalived Routing Schemes

2.1 Why a Routing Scheme Is Needed

After Keepalived selects a real server via its load‑balancing algorithm, two additional steps are required:

How Keepalived forwards the request to the chosen server.

How the server returns the response to the client.

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

2.2 Where It Is Configured

The routing mode is set in keepalived.conf via the lb_kind directive, which can be NAT , DR , or TUN . The current configuration uses DR mode. The load‑balancing algorithm is defined by lb_algo , e.g., wrr (weighted round‑robin).

2.3 LVS Structure

Keepalived leverages the Linux Virtual Server (LVS) module, consisting of a front‑end load balancer (LB) and multiple back‑end 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 private IPs. In the restaurant analogy, NAT corresponds to the standard order‑to‑dish flow where waiters hand orders to the runner, who notifies the chef, and the chef returns the dish via the runner.

Typical NAT setup:

eth0 → Public VIP → External Network
eth1 → Private VIP → Internal Switch

Workflow:

Client sends request to the public VIP.

The main LVS router replaces the destination address with a NAT VIP.

The request is load‑balanced to a real server.

LVS rewrites the packet’s destination IP/port to that of the chosen server.

The real server processes the request and replies to the LVS router.

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

From the client’s perspective, only the public VIP is visible; the NAT VIP and real server IPs are hidden.

3.2 TUN Routing Scheme

TUN (tunneling) encapsulates the original packet inside another IP packet, similar to a VPN. The encapsulated packet is sent directly to the real server, which must be reachable from the external network.

Advantages: eliminates the LVS router as a bottleneck because the real server returns responses directly to the client.

Drawbacks: requires all real servers to support IP tunneling and have routable IPs.

3.3 Direct Routing (DR) Mode

DR also forwards client requests to a real server, but the real server shares the virtual IP (VIP) with the LVS router and replies using that VIP. No IP tunneling is needed, and both LVS and RS must reside in the same LAN broadcast domain.

Key points:

ARP requests for the VIP are answered only by the LVS router (Director Server).

Real servers remain silent on ARP for the VIP.

Clients always send to the VIP; the router rewrites the destination MAC to the chosen RS’s MAC.

4. Comparison of the Three Modes

Overall, DR mode is recommended for most scenarios due to its simplicity and lower overhead, provided the real servers share the same LAN as the LVS router.

5. Bonus: VRRP and ARP Details

A reader asked whether the master node sends VRRP or ARP broadcasts to the backup. The answer:

The master sends VRRP advertisements containing the priority field via vrrp_send_adv(vrrp_t *vrrp, uint8_t prio) .

The master also broadcasts ARP requests to announce its IP‑MAC mapping.

During a failover, the VIP remains unchanged, but the MAC address changes; clients update their ARP cache accordingly.

Source code snippets:

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

Images illustrating the analogies and diagrams are retained from the original article.

In summary, Keepalived offers three routing options, each with distinct trade‑offs; DR is generally preferred when the environment permits.