Layer 2 DSR

Layer 2 Direct Server Return is the simplest and most efficient DSR mode available in Tula. It operates by rewriting the destination MAC address of incoming packets, forwarding them at the data link layer to the selected backend server. Because L2 DSR works below the IP layer, it introduces virtually no overhead and preserves the original client IP address without any additional configuration.

How L2 DSR Works

When a client packet arrives at the load balancer's VIP, the L4 engine (nftlb) selects a backend server and rewrites the Ethernet frame's destination MAC address to that of the chosen backend. The IP headers remain completely untouched -- the destination IP is still the VIP address. The backend server, configured to accept traffic for the VIP on its loopback interface, processes the request and responds directly to the client.

Because the packet is forwarded at Layer 2, all servers -- the load balancer and every backend -- must reside on the same Layer 2 network segment (broadcast domain). The packet is delivered via normal Ethernet switching; no routing or encapsulation is involved.

Network Requirements

L2 DSR requires that the load balancer and all backend servers share a common VLAN or broadcast domain. If your backends span multiple subnets or physical sites, you must use Layer 3 DSR instead.

Ensure that your network switches have sufficient MAC address table capacity and that spanning tree convergence times are acceptable for your availability requirements.

Configuring L2 DSR in Tula

To enable L2 DSR for a Layer 4 VIP in the Tula web interface:

Navigate to Load Balancing > L4 Virtual IPs and select the VIP you want to configure, or create a new one.
Set the Mode to DSR and the DSR Type to Layer 2 (MAC).
Add your backend servers, specifying their IP addresses. Tula will resolve the corresponding MAC addresses automatically.
Configure the scheduling algorithm (round robin, weighted, least connections, or source hash) as needed.
Save the configuration and apply changes.

Backend Server Configuration

Each backend server must be configured to accept traffic destined for the VIP address and must not respond to ARP queries for that address. This prevents the backend from claiming ownership of the VIP on the network, which would cause traffic to bypass the load balancer.

Configure the VIP on the loopback interface:

ip addr add <VIP_ADDRESS>/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

Set arp_ignore=1 so the server only responds to ARP requests for addresses configured on the interface the request arrived on. Set arp_announce=2 so the server uses the best local address for ARP source, avoiding announcing the VIP via the physical interface.

To persist these settings across reboots, add the sysctl values to /etc/sysctl.d/99-dsr.conf and add the loopback address to your network configuration (e.g., via netplan on Ubuntu).

Advantages of L2 DSR

Simplest configuration. No tunnels, no encapsulation, no MTU adjustments.
Lowest overhead. MAC rewriting is a trivial operation with negligible CPU cost.
Full transparency. The original client IP, TCP ports, and all IP headers are preserved unmodified.
Broad compatibility. Works with any TCP or UDP protocol without application-level awareness.

Limitations

Same broadcast domain required. All backends must be reachable via Layer 2 from the load balancer.
Scalability constraints. Very large L2 domains can introduce broadcast storms and MAC table exhaustion on switches.
No cross-site deployment. L2 DSR cannot span data centres or routed network boundaries.

For deployments where backends are on different subnets or in different locations, consider Layer 3 DSR which uses IP-in-IP tunneling to route DSR traffic across Layer 3 boundaries.