LVS Forwarding Methods

Linux Virtual Server (LVS) supports several forwarding methods to distribute client requests among real servers. The most common methods are NAT, Direct Routing (DR), and Tunneling (TUN). Additionally, the concept of "Local Node" refers to handling traffic on the load balancer host itself when it is also configured as a real server. Below is an overview of each method:

1. NAT (Network Address Translation)

• How It Works: In LVS-NAT mode, the load-balancing director receives client requests and performs destination network address translation. It rewrites the destination IP address to one of the real server’s IP addresses and forwards the packet. When the real server replies, the director again translates the source IP address from the real server back to the virtual IP (VIP) before sending the response to the client.

• Advantages:

  • Simplifies network configuration since all responses appear to come from the director.

  • Works well when real servers are in different subnets.

• Disadvantages:

  • Increases load on the director because all traffic (both incoming and outgoing) must pass through it.

  • Introduces extra processing overhead due to address translation.

2. Direct Routing (DR)

• How It Works: In LVS-DR mode, the director receives the client request and, without modifying the IP header, changes the destination MAC address to that of the chosen real server. The real server receives the packet, processes it, and sends the response directly to the client, bypassing the director. For this to work, all real servers must share the same VIP, and they must be configured to ignore ARP requests for the VIP.

• Advantages:

  • High performance with minimal overhead since only incoming traffic is handled by the director.

  • Scales well in large deployments.

• Disadvantages:

  • Requires careful network configuration, particularly regarding ARP suppression.

  • Only works when the director and real servers are on the same subnet.

3. Tunneling (TUN)

• How It Works: In LVS-TUN mode, the director encapsulates client requests into IP tunnels (commonly using IP-in-IP or GRE). The tunneled packets are then forwarded over the network to the real servers, which decapsulate the packets, process them, and send responses directly to the client. This method allows real servers to reside on different subnets from the director.

• Advantages:

  • Provides flexibility in network topology as real servers can be located in remote networks.

  • Allows for load balancing across geographically dispersed servers.

• Disadvantages:

  • Introduces extra overhead due to encapsulation and decapsulation.

  • May increase latency compared to DR.

4. Local Node

• Concept Overview: "Local Node" generally refers to a scenario where the director is also a real server and processes requests locally without forwarding them over the network. In such a configuration, if a client request is directed at the VIP and the director is configured to also handle that service, the packet is processed on the local node rather than being forwarded to another machine.

• Advantages:

  • Eliminates unnecessary network hops, thereby reducing latency.

  • Simplifies configuration in setups where the load balancer is also serving as one of the real servers.

• Disadvantages:

  • The director’s resources are shared between load balancing and service processing, which might lead to performance contention.

  • Not ideal in environments that require strict separation between the load balancer and service nodes.

Summary Table

Method	Traffic Flow	Pros	Cons
NAT	Director modifies packet addresses; all traffic goes through director.	Simplified routing; works across subnets.	Higher load on director; extra processing.
Direct Routing	Director changes MAC address; real servers reply directly to clients.	High performance; low overhead.	Requires same subnet; complex ARP handling.
Tunneling	Director encapsulates packets; real servers decapsulate and reply directly.	Flexible topology; supports remote servers.	Extra overhead; increased latency.
Local Node	Director processes requests locally when also a real server.	Low latency; no extra network hop.	Resource contention on the director.

Conclusion

LVS offers multiple forwarding methods tailored to different network environments and performance requirements:

• NAT is useful when real servers are in different subnets and simplicity is needed, albeit with higher overhead on the director.

• Direct Routing (DR) is optimal for high-performance, low-latency environments where all nodes share the same subnet.

• Tunneling (TUN) provides flexibility for geographically dispersed servers but incurs additional encapsulation overhead.

• Local Node mode enables the director to serve requests locally when it also functions as a real server, reducing network delays but potentially sharing load with balancing operations.

Choosing the appropriate forwarding method depends on the specific requirements and constraints of your deployment.