Configuring Direct Server Return

You are here: Working with Clusters and Match Rules > Configuring Direct Server Return

Configuring Direct Server Return

In a typical load balancing scenario, server responses to client requests are routed through FortiADC on their way back to the client. FortiADC examines the headers of each response and may insert a cookie, before sending the server response on to the client.

In a Direct Server Return (DSR) configuration, the server receiving a client request responds directly to the client IP, bypassing FortiADC. Because FortiADC only processes incoming requests, cluster performance is dramatically improved when using DSR in high bandwidth applications, especially those that deliver a significant amount of streaming content. In such applications, it is not necessary for FortiADC to receive and examine the server’s responses: the client makes a request and the server simply streams a large amount of data to the client.

DSR is supported on Layer 4 TCP and UDP clusters only, and is not supported for FTP clusters (Layer 4 TCP clusters with a start port of 21). Port translation or port mapping is not supported in DSR configurations.

DSR configurations are usually configured in single network mode, where the cluster IP and the server IPs are all on the internal interface. An example single network mode DSR configuration is shown below:

DSR can also be used in dual network mode, although this is a less common configuration than single network mode. Cluster IPs are on the external interface, and server IPs are on the internal interface. An example of a dual network mode DSR configuration is shown below.

Note - In both configurations that the incoming client traffic is assumed to originate on the other side of the gateway device for the subnets on which FortiADC and the servers reside. The servers will usually have their default gateway set to something other than FortiADC so that they can respond directly to client requests.

The cluster parameters Direct Server Return, Spoof, and Idle Timeout are directly related to direct server return connections:

Direct Server Return - this option enables Direct Server Return. All requests to this cluster IP will be forwarded to the server with the client IP as the source IP, and the cluster IP as the destination IP. The loopback interface of the server must be configured with the cluster IP to receive the requests. See “Configuring Servers for Direct Server Return” on page 183.
Spoof - this option causes FortiADC to spoof the client IP address when FortiADC routes a request to a server in a virtual cluster; that is, the IP address of the client is sent to the server, not the IP address of the FortiADC. This flag must be enabled for DSR.
Idle Timeout - The is the time in seconds before reclaiming idle Layer 4 connection records. Applies to Layer 4 TCP clusters only. For DSR the Idle timeout slider must be set to a non-zero value, or FortiADC will never reclaim connection records for connections terminated by the server. The cluster's Idle Timeout should be set to the longest period within your application that you would like FortiADC to wait for consecutive messages from the client (since the FortiADC does not see server packets on DSR connections). For example, if the longest expected server response time and the longest expected delay between client responses on active connections are both 60 seconds, then set the Idle Timeout slider to 120 seconds.

To create a new cluster or modify an existing one for DSR, do the following:

Log into the GUI using a login that has add/del access for the cluster (See Logging In.)
Do one of the following:

Create a new Layer 4 TCP or UDP cluster: right-click FortiADC in the left navigational pane and select Add Cluster. After you enter and commit the basic information, you’ll be taken to the server Configuration tab.

Modify an existing Layer 4 TCP or UDP cluster: click on the cluster name in the left frame to display the cluster’s Configuration tab in the right frame.

Enable the Direct Server Return and Spoof check boxes.
If the cluster is a Layer 4 TCP cluster and the idle timeout parameter is set to 0, increase it as described in the table above. Skip this step for Layer 4 UDP clusters.
Click on Commit to save your changes to the cluster configuration.

If you need to add server instances to a server pool, add them by doing the following:

Right-click the server pool name in the left navigational pane frame and select Add Server Pool.

Fill in the remainder of the required information.

Click on the Commit button to save your entries.

Perform the procedure in the following section on each server that you add to the cluster.