Kemp Support, how can we help?

The latest application delivery knowledge and expertise at your fingertips.

  1. Kemp Support
  2. Knowledge Base
  3. Routing and Switching

How Direct Server Return (DSR) works?

Updated: 

Direct Server Return (DSR) is a method whereby traffic hits the LoadMaster on the way in and bypasses the LoadMaster on the way out.

This feature was created to deal with a specific problem. When response traffic is greater than the request traffic, a load balancer could become a bottleneck. This is particularly relevant when using sensitive real-time applications like UDP services delivering real-time video and audio content.

Other reasons can include the need for transparency when the client is in the same subnet as the Real Server.

The traffic flow in the diagram below is as follows:

  1. The incoming request is intercepted by the LoadMaster.
  2. The request gets routed to Server 1.
  3. Server 1 responds.
  4. The response goes directly to the client, without going through the LoadMaster.

DSR.png

DSR should only be implemented if the Real Servers need to respond to the clients directly, without going through the LoadMaster. In this configuration, the Real Servers must have a path to the clients without going through the LoadMaster, for example, an additional router in parallel with the LoadMaster.

Note: The only persistence option supported in a DSR configuration is Source IP. No Layer 7/Application features can be used with DSR. Also, DSR may be used only in a 1-arm configuration due to routing issues caused on the Real Server with the loopback interface in a 2-arm solution.

DSR uses a combination of MAT (MAC Address Translation) and a modified Real Server configuration. The Real Server is configured with an IP address as normal but it is also given the IP address of the Virtual Service. Normally you cannot have two machines on a network with the same IP address. To get around this, the Virtual IP (VIP) address on a Real Server must be configured so that the server does not respond to ARP requests on the VIP address.

For further information on how to configure Real Servers (both for Linux and Windows) please refer to the Configuring Real Servers for DSR Technical Note document.

 

After configuring DSR, the traffic flow might leave you scratching your head because a packet capture can look strange. The LoadMaster forwards the request from the client to the loopback adapter. The client's IP and Virtual IP always remains the same. However, the MAC addresses will be changed.

The below diagram shows the traffic flow. The client performs a three-way handshake with the Virtual IP. Each client request is forwarded to the loopback address on the Real Server (blue lines). The response from the Real Server is returned directly to the client (red lines). This traffic will not flow back through the LoadMaster as it is routed through the Real Server's gateway. 

DsrFlow.png
 
The attached PCAP in the screenshots below shows the client's request. You will not see the response as this goes directly back to the client. You will see what appears to be duplicate packets or re-transmits. Wireshark is not aware that the LoadMaster is using Direct Return and reads the packets appropriately. However, checking the Ethernet header reveals that the source and destination MAC addresses are different from the client's request.
 
Here is the client sending a SYN to the Virtual Service:
Trace_Client_VIP.png
 
This is then forwarded by the LoadMaster to the Real Server. As you can see, the MAC addresses have changed:
Trace_VIP_Real_Server.png
Was this article helpful?
0 out of 0 found this helpful

Comments

In this document