How to Configure Direct Server Return

Direct Server Return (DSR) allows backend servers to respond directly to clients, bypassing the load balancer on the return path. For workloads with asymmetric traffic patterns -- where responses are much larger than requests -- DSR can reduce load balancer bandwidth requirements by 90% or more.

When to Use DSR

DSR is the right choice when your workload has large responses relative to requests:

• Media streaming -- Small HTTP requests producing multi-megabyte video or audio responses.
• Large file downloads -- Software distribution, ISO images, and CDN origin servers.
• High-throughput APIs -- Bulk data exports and search services returning large result sets.
• Gaming and real-time services -- High packet-rate UDP services with strict latency requirements.

If your service requires Layer 7 features such as content-based routing, cookie persistence, or HTTP header manipulation, DSR is not appropriate. Use a standard L7 VIP instead.

Choosing Between L2 and L3 DSR

Tula supports two DSR modes, and the choice depends on your network topology:

Layer 2 DSR (MAC rewrite) -- The load balancer rewrites the destination MAC address of incoming packets to the selected backend's MAC address. The IP headers are untouched. This requires all backends to be on the same Layer 2 network segment (VLAN) as the load balancer. L2 DSR has the lowest overhead and is the preferred mode when the network topology allows it.

Layer 3 DSR (IPIP tunneling) -- The load balancer encapsulates the original packet inside an IP-in-IP tunnel to the backend server. The backend decapsulates the outer header and processes the original packet. This works across subnets and routed networks, making it suitable for backends in different data centres or VLANs. L3 DSR adds a small overhead due to encapsulation (20 bytes per packet).

Step 1: Create an L4 VIP with DSR Mode

1. Log in to the Tula web interface and navigate to Load Balancing > Virtual IPs.
2. Click Add VIP.
3. Configure the VIP:
   • Name: A descriptive name (e.g., streaming-dsr).
   • IP Address: The virtual IP that clients will connect to.
   • Port: The service port (e.g., 80, 443, or * for all ports).
   • Protocol: Select TCP or UDP. DSR is a Layer 4 feature and requires an nftlb-based VIP.
   • Mode: Select DSR - Layer 2 or DSR - Layer 3 depending on your network topology.
   • Algorithm: Choose a scheduling algorithm. Round Robin or Least Connections are common choices.
4. Click Save.

Step 2: Add Backend Servers

1. In the VIP configuration, navigate to the Backends section.
2. Click Add Backend for each server.
3. Provide the backend's Name, IP Address, Port, and Weight.
4. For L2 DSR, the backend IP must be reachable on the same Layer 2 segment. For L3 DSR, any routable IP is acceptable.
5. Click Save after adding all backends.

Step 3: Configure Backend Servers

Each backend server must accept traffic destined for the VIP address and suppress ARP responses for that address. On each Linux backend, run the following commands (replace 10.0.1.100 with your VIP address):

# Add the VIP to the loopback interface
ip addr add 10.0.1.100/32 dev lo

# Suppress ARP responses for the VIP
sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

To make these changes persistent across reboots, add the IP to your network configuration and add the sysctl entries to /etc/sysctl.d/99-dsr.conf:

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

For L3 DSR (IPIP tunneling), you must also enable the IPIP tunnel interface on each backend:

modprobe ipip
ip link add ipip0 type ipip local <backend-ip> remote any
ip link set ipip0 up
ip addr add 10.0.1.100/32 dev ipip0

Step 4: Apply Configuration and Test

1. In the Tula web interface, click Apply Configuration to activate the VIP.
2. Test connectivity from a client machine:

curl -v http://10.0.1.100/

3. Navigate to Monitoring > Statistics to verify that traffic is being distributed across backends.

Troubleshooting Tips

• Connection timeouts: Verify that the VIP address is configured on each backend's loopback interface. Run ip addr show lo on each backend to confirm.
• ARP conflicts: If clients intermittently connect directly to a backend instead of the load balancer, the backend is responding to ARP requests for the VIP. Confirm that arp_ignore and arp_announce are set correctly with sysctl net.ipv4.conf.all.arp_ignore.
• L3 DSR not working: Ensure the ipip kernel module is loaded (lsmod | grep ipip) and that the tunnel interface is up on each backend. Check that no firewalls are blocking IP protocol 4 (IPIP).
• Asymmetric routing: Ensure that the backend's default gateway allows it to reach the client directly. The return path must not require passing through the load balancer.